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AUTOMATIC BROKER TOOLS AND 
TECHNIQUES 

RELATED APPLICATIONS 

This application claims priority to, and incorporates by 
reference, commonly owned copending U.S. Patent Appli- 
cation No. 60/134,383 filed May 15, 1999. 

FIELD OF THE INVENTION 

The present invention relates to the technical goal of 
providing prospective buyers and sellers of digital content 
with information and assurances, and relates more particu- 
larly to sampling, escrow, and barter tools and techniques for 
an automated broker to facilitate a market in digital content. 

TECHNICAL BACKGROUND OF THE 
INVENTION 

Advances in computer technology have created an enor- 
mous body of digital content, namely, content stored as bits 
in some computer-readable medium. Some categories of 
digital content have widely used non-digital counterparts. 
For instance, books are still more widely available in paper 
form than in digital form. Other categories of digital content 
exist primarily or solely in response to the widespread use of 
digital computers; examples include databases and software. 
Some categories of digital content exist primarily to enter- 
tain. Others reflect research, development, or marketing 
efforts. Regardless of such distinctions, one result of the 
computer revolution is a growing body of valuable artistic, 
technical, business, academic, and other content stored in 
various digital formats. 

Another result of the computer revolution is relatively 
easy communication of digital content. The Internet 
(including the World Wide Web), email, "instant messaging" 
services, "chat rooms", news groups, electronic discussion 
forums and bulletin boards, and other computer-aided 
avenues of communication are now available in many parts 
of the world. One might expect these communication tools 
to support a thriving market in the growing body of digital 
content. Indeed, much digital content is advertised, 
purchased, and/or delivered through the Internet and other 
computer-assisted communication tools. 

For example, demonstration versions of computer soft- 
ware can be downloaded by prospective users without any 
direct human action, once the software owner selects the 
software version and places a copy of the selected software 
on a web site, FTP site, or other electronically accessible 
location. Full-function versions can also be paid for and then 
obtained through commercial transactions that require little 
or no direct human action, other than having the seller 
initially provide a master copy of the software and having 
each buyer provide payment informatioQ such as a credit 
card number. Shareware software can similarly be down- 
loaded using computer programs as intermediaries, rather 
than relying on a human sales clerk. In short, online software 
shops are well-known. 

Moreover, transactions involving goods other than soft- 
ware can also be performed using software sales "person- 
nel". Auction sites such as www.ebay.com facilitate trans- 
actions involving software and many other types of goods, 
both digital and non-digital. Reverse auction or "demand 
collection" sites such as www.priceline.com facilitate trans- 
actions involving both goods and services. 

These and/or other "e-commerce" sites offer prospective 
buyers and competing sellers information about goods and 
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services of virtually every type, and many sites also allow 
one to purchase goods and/or services on-line. To give just 
a few examples, web sites exist to advertise and/or sell 
patent rights, games, software, books, mortgage services, oil 

5 and gas properties, medical supplies, scientific equipment, 
factory simulation services, insurance services, computers, 
management consulting services, investment banking 
services, and "adult" content and services. Sellers' sites 
generally provide textual descriptions of the goods and/or 

10 services being offered, and many offerings also include 
images and/or sounds that represent or constitute the offered 
goods and/or services. The images may be still images, 
video clips such as those in MPEG or AVI format, or 
user-navigable images such as those in the IPIX format. 

15 The images sometimes include samples in the form of 
partial images or thumbnail images. These samples are 
apparently selected by the seller and/or approved by the 
seller for posting based on the seller's understanding of the 
techniques used to create the samples. That is, the seller 

20 apparently knows what prospective buyers will see when 
they view the samples. If the goods are digital images, these 
samples may be presented with the promise that complete 
and/or larger images are available to be downloaded in 
exchange for payment. Similarly, video and/or audio clips 

25 showing part of a work may be presented to encourage 
purchase of a copy of the complete work. 

Despite the enormous amount of activity in electronic 
commerce, problems remain. One factor that makes the 
market in digital content risky is the ease with which most 

30 digital content can be copied. Of course, many efforts have 
been made to reduce unauthorized use of digital content. For 
instance, copyright laws, other intellectual property laws, 
encryption that prevents use of a product without user 
registration and/or payment, other technical measures, and 

35 the basic honesty of many people, can each provide some 
protection against the theft of digital content. 

But a content owner may still be justifiably reluctant to 
make that content available for inspection by prospective 

4Q buyers, lest the content be copied and used without paying 
the owner. On the other hand, buyers may quite reasonably 
want to inspect the digital content before they pay for it. 
Unless the buyer and the seller have a working relationship 
based on successful completion of earlier transactions, or 

45 trust each other for some other reason, the lack of trust can 
prevent successful completion of the transaction even when 
such completion would benefit both parties. 

To help illustrate the issues of trust involved in a trans- 
action between a seller and a buyer, we define some notation. 

50 This notation, or similar notation, may have been used 
previously but the notation itself is not the invention. Rather, 
the notation is used in this Technical Background to describe 
prior approaches to marketplaces in digital content, and it is 
also used in later sections to describe the present invention, 

55 just as English (or another language) can be used for both 
purposes. That is, the fact that the notation is used in 
discussing both past approaches and the present invention 
does not mean that the invention described with that notation 
was previously known. 

60 Naming the initial participants and items involved is 
straightforward: we use "S" to denote a seller, "B" for a 
buyer, "G" for the goods or services being sold, and "$" for 
payment (understanding that other currencies than U.S. 
dollars may also be used). 

65 If all goes well a seller S transfers goods G to a buyer B 
and receives payment $ as compensation. But the order of 
events in the transaction can be very important, so the 
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notation also describes different orders. When S hands B the If the description and/or sample provided in step (1) are 

goods and then receives the payment, in that order, the steps faulty, then the payment in step (2) may be too high. For 

in this transaction may be represented as: instance, the quality of the goods may be lower than the 

S-G->B; S<-$-B. sample led the buyer to expect. Even if any description 

Diagrams or other notation could also be used; the nota- 5 an d/ or sample provided in step (1) are accurate, seller S may 

tion above has the advantage of not requiring special char- ^ ^ m ^ ^ ^ ^ degired st (3) doesQ , t 

acters or any drawing (graphics) facility. It the seller first . t» *jti t> > c j * * * *l * 

receives payment and only then turns over the goods to B, ° ccur as bu y er * ex P ect * d * is forced to trust that 

the transaction may be represented as: descriptions and/or samples provided by seller S accurately 

S<-$-B* S-G->B represent the goods G, and buyer B is also forced to trust that 

or 10 seller S will not disappear after being paid, leaving buyer B 

S<-$-B without the goods G for which B paid. 

S-G->B ^ alternative is transaction T2, which is illustrated in 

If we do not know or do not care about the order (either FIG - 2 and described by the notation as follows: 

act may occur first, or they may partially or completely 55 1. ?(S-D->B) || ?(S-M->B) 

overlap each other), then the transaction is shown as: 2 S-G->B 

(S-G->B || S<-$-B) ^ S< $ B 

or, equivalently, as. approach forces seller S to trust that buyer B will not 

(S<-$-B || S-G->B) , . . . simply take the goods and fail to make payment in the 

Finally, if the two acts must overlap in time, we write: 20 desired step (3) 

(S-G->B && S<-$-B) Another alternative is transaction 13: 

0 ^l t i y S-G->B). 1 . ? (S-D->B),|,(S-M->B) 

A single "I" means "or" in the sense of one act or another h, S" 0 "^ & & S<-$-B 

act or both acts being done. A single means "and" in the 25 T*** A» «U« and the buyer each hand the other the 

sense of both acts being done. goods and the payment, respectively, at essentially toe same 

S and B will often negotiate before exchanging goods and tlme -. ^ be 6 ood ™ bUt U 15 m 

payment, with one or more offers, counteroffers, conditions, Police Each must trust the other not to outwit or over- 

and/or acceptances before goods and payment are P ower ^ and ^ leave Wlth botb S°° ds and ,h <; 

exchanged. Such negotiations are written as: 30 payment, leaving one party empty-handed. To succeed 

S< N >B reliably, 13 requires matching levels of trust and power, 

rr» « KT „ . j c u .. 4 . , ^„ , 4l _ . which are relatively rare when one looks at the wide ranee 

The "N stands for negotiation(s) and the arrow is c , L , ' ^ n , „ 4 £ , 

u .j. i * • j- * * u u i \ & . » 4 r + ol parties that could mutually benefit from completing a 

bidirectional to indicate the back-and-forth nature of most 

,. . transaction with each other. 

11 c -ii ^ ■ j / * i .« * -n M1 35 Each of these transactions can be improved somewhat by 

The seller S will often provide (and/or the buyer B will ^ « . , ^ , . f iL A . A1 _ f 

• \ i . r ,f i c j tt. having each party learn more about the other through 

require) a description and/or a sample of the goods. These . . , , , 

' . • * j -*u *\ negotiations, using transactional approaches such as those 

events can be represented (and annotated with comments) ~. . -,i * * , • ^ , ■ * • „ 

V1 ■ r v 7 which are illustrated in FIG. 3 and summarized in the 

like this: - „ . A A . 

c ™* ti / / j • * * j t following notation: 

S-DM->B //description and sample Transaction TIN: 

S-D->B //description only 0 , c n m , m 

c n // i i 1 ' H S " D " >B ) ?(S-M->B) 

S-M->B //sample only 

Hie sample M is a conventional sample, that is, it is o<-JN->B 

obtained using tools and techniques which are known in the 3- S<-$-B 

art and it is provided in the context of conventional com- 45 4. S-G->B 

mercial transactions. As explained later, the present inven- Transaction T2N: 

tion provides novel samples, samples which are obtained by \ m 7(S-D->B) || 7(S-M->B) 

novel tools and/or techniques, and/or samples which are 2 S< N >B 
used in the novel context provided by the invention. 

If a step is optional, we precede it by "7". For instance, if 5Q a-G->B 

the seller's provision of a sample can be either present or 4. S<-$-B 

omitted without substantially altering the trust (or other) Transaction T3N: 

issues being discussed, but negotiation is essential, we could 1. 7(S-D->B) || 7(S-M->B) 

write: 2. S<-N->B 

(S<-N->B || 7(S-M->B)); (S-G->B || S<-$-B) 55 3 S . G _ >B && S< . $ _ B 

The notation could be made even more complex, borrow- But trust Tcm ^ T n TIN, B might not receive 

ing ideas from areas like computer programming, logical accurate samples and descriptions, and B might not receive 

calculus, and multiprocessing, but the notation is not the ^ goods or services after paying for them. In T2N, S might 

goal. Understanding and improving transactions is the goal. not receive payment after providing the goods or services. In 

We will use the notation aad/or Figures hereafter. 60 ^N, cach party may bc at risk of bcing outwitted or 

Consider some trust issues, which may depend on the overpowered by the other, 

order of events in a transaction. For instance, consider Anothcr sct of ^^^5 use a conventional agent A 

transaction Tl, which is illustrated in FIG. 1 and described such as a broker> attorney , banker, or other "trusted third 

by the notation as follows: partyJ > WQ0 is trusted by of beilJg neutral> bon ded, 

1. ?(S-D->B) || ?(S-M->B) 65 licensed, and/or regulated, for example. Trie agent A is a 

2. S<-$-B human, or an institution directly operated and controlled by 

3. S-G->B humans. One transaction T4 involving seller S, buyer B, 



02/24/2003, EAST Version: 1.03.0002 



US 6,343,738 Bl 

5 6 

agent A, goods or services G, payment $, and approvals OK BRIEF SUMMARY OF THE INVENTION 

is illustrated generally in FIG. 4. Time advances as one rp, . . , , . , . , 

r *if * £ 4L c * j .1 i j The present invention relates to methods, articles, signals, 

moves trom the top or the Figure toward the bottom. In the , . r £ . . . . f. ; 

notation we have been using, the transaction T4 goes some- and f ° r f a ° h 1 U, V 1 8 elec ' roiuc commerce in digital 

thing like this - goods. Examples or digital goods include musical works, 

1 ?(S D >B) II ?CS M >B) 5 v ^ ua ^ works, and other artistic works in digital form; patent 

J * T Ll , , , , ✓ ^ „ applications, engineering documents. CAD files, and other 

S n ? e step or p ,echnical informalion in f orm ; sof tware ; mai,in e 

an o ow, or overlap customer databases, and other marketing information in 

3. A<-$-B // agent A receives money from buyer; A digital form; intellectual property rights in patents, 
"holds" or "escrows" the $ 10 copyright trademarks, trade secrets, and/or technical or 

4. S<-OK-A // A confirms to S that A has the payment marketing know-how; and other information in digital form 

5. S-G->B that does or may possess commercial value. The invention 

6. S<-OK-B || A<-OK-B // B OK's the goods and OICs facilitates commerce in such goods by reducing or elimi- 
payment completion nating barriers by providing an improved basis for the 

7. S<-$-A // A releases the funds to S 15 parties to expect successful completion of the desired trans- 
However, agent A must be trusted by both seller S and action. 

buyer B. A must be trusted by B, lest A leaves with the In a transaction according to one embodiment of the 

payment after step (3). B must also trust A to perform step invention, each of the two or more parties to a transaction 

(7) when, and only when, approval is given to A by B in step ^ provides an inventive automatic broker with (a) the ability to 

(6). A must be trusted by S, lest A leaves with the payment deliver some item of value to one or more of the other 

after step (3), or receives the payment but denies receiving parties, such as goods or payment, and (b) conditional 

it (no step (4)). There are other ways for the transaction to authorization to deliver that item. Each party then reviews 

go wrong if trust is undeserved (such as partial payments or information from the other party or parties (often sent by 

damaged goods or faulty timing), but these suffice for now. way of the broker) and approves or cancels completion of 

Another transaction T5 involving an agent goes like this: the transaction. If the parties approve completion, then the 

1. ?(S-D->B) || ?(S-M->B) broker effects the transfers. Otherwise, the broker returns the 

2. ?(S<-N->B) // could also precede (n), or precede and digital items of value, releases its hold on them, and/or 
follow, or overlap deletes them, such that the broker no longer has the ability 

3. (A<-$-B || S-G->A) // agent receives money from buyer 30 to deliver the items. 

and goods from seller Unlike some conventional approaches to transactions, all 

4. (A-OK->B || S<-OK-A) // agent confirms goods & brokering functions can be provided automatically. This 
payment OK and in hand reduces cost, increases transaction throughput, and reduces 

5. (A-G->B || S<-$-A) // agent releases goods to buyer & the opportunity for transactions to fail due to mistakes or bad 
payment to seller 35 acts by a broker. 

Again, agent A must be trustworthy and trusted. In particular, digital goods can be escrowed with an 

Otherwise, for instance, A could improperly retain posses- automatic broker by providing the broker with a copy to be 

sion of both the goods and the money after step (3). A could stored on a medium accessible only to the broker (or at least 

also intentionally misrepresent the amount, quality, or not reasonably accessible to the party that provided the 

receipt of the goods, and/or the amount, quality, or receipt of 40 goods to be escrowed). Goods could also be escrowed on a 

the payment in step (4). A could also release an item (goods medium that is accessible to the party that provided the 

or payment) to one party but not release the other item in goods, by encrypting them and/or digitally signing them so 

step (5) if A improperly favors one party unbeknownst (at am/ changes made after they are provided to the broker can 

least beforehand) to the other. be prevented or can at least be detected by the broker and/or 

In short, conventional approaches to commercial transac- 45 l he buyer. However, placing copies at a location not known 

tions pose significant risks to buyers and sellers. These risks to me seller and/or not accessible to the seller is preferred, 

are increased by the ease with which digital goods can be since preventing the seller from retrieving all copies of the 

copied once they are made available for inspection. The escrowed goods will significantly reduce the risk that the 

need for trust is also increased by the fact that the Internet seller will prevent a buyer from receiving the goods after 

and other communications media make it more likely than 50 paying (or bartering) for them. 

ever that a prospective buyer and prospective seller do not Payments, such as credit card holds, bank transfers, 

have a history of successfully concluded transactions (at digital cash, and the like, can also be escrowed by the broker, 

least not with each other), and that they may well be In transactions that exchange goods for goods (i.e., barter 

separated by long geographic distances, by different natural transactions) rather than exchanging goods for payment, all 

languages, by different national laws, and/or by cultural 55 of the digital goods can be held in escrow by the broker 

differences. pending authorization from the parties to complete the 

Accordingly, it would be an advance to provide tools and transaction, after which the goods are released by providing 

techniques which make it easier for prospective buyers to copies to the parties, as previously specified by the parties, 

inspect digital goods without thereby creating a significant Note that "payment" is used herein to mean cash, currency, 

risk that those goods will be copied, and hence stolen, by 60 or similar liquid payment, as opposed to goods or services, 

someone who is merely posing as a buyer. The automatic broker can generate samples of digital 

More generally, it would also be an advance to improve goods, to be provided by the broker to a prospective buyer, 

the market for digital content by providing tools and tech- Samples can also be provided to the seller, but this is not 

niques which reduce and/or meet the need for the parties in always necessary or appropriate. In some embodiments, the 

a transaction to trust each other. 65 seller does not know what technique will be used to generate 

Such tools and techniques are disclosed and claimed the sample, so the seller is discouraged from providing 

herein. goods that will pass inspection only if a particular sampling 



02/24/2003, EAST Version: 1.03.0002 



US 6,343,738 Bl 



8 



technique is used. The sampling techniques preferably per- 
mit the buyer to inspect the goods without thereby making 
the goods available for use by the buyer without purchase. 
Samples can also be provided in a catalog, to be browsed by 
specified or unspecified parties. For instance, a catalog 5 
might be open to general access within a company, or open 
to the public at large. Other aspects and advantages of the 
present invention will become more fully apparent through 
the following description. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

To illustrate the manner in which the advantages and 
features of the invention are obtained, a more particular 
description of the invention will be given with reference to 
the attached drawings. These drawings only illustrate 15 
selected aspects of the invention and thus do not limit the 
invention's scope. In the drawings: 

FIG. 1 is a flowchart illustrating a prior art approach to 
transactions involving digital and/or non-digital goods, in 2Q 
which the buyer provides payment and the seller then 
provides the goods in response. 

FIG. 2 is a flowchart illustrating a prior art approach to 
transactions involving digital and/or non-digital goods, in 
which the seller provides the goods and the buyer then 2 5 
provides the payment in response. 

FIG. 3 is a flowchart illustrating prior art approaches to 
transactions involving digital and/or non-digital goods, 
including negotiations between seller and buyer, and show- 
ing alternatives in which the seller provides the goods and 30 
the buyer provides the payment in various orders. 

FIG. 4 is a data flow diagram illustrating a prior art 
approach to transactions involving digital and/or non-digital 
goods, in which a conventional agent acts as an intermediary 
between the seller and the buyer. 

FIG. 5 is a data flow diagram illustrating embodiments of 
the present invention with transactions involving at least 
some digital content, in which a novel automatic broker acts 
as an intermediary between the seller and the buyer, the 
broker receives the digital content from the seller, the broker 40 
provides samples based on that digital content to the buyer, 
and the broker completes the transaction by releasing pay- 
ment to the seller and releasing the digital content to the 
buyer. 

FIG. 6 is a data flow diagram illustrating embodiments of 
the present invention with transactions similar to those 
illustrated in FIG. 5, in which the novel broker also provides 
the seller with at least one sample which is being provided 
to the buyer to permit evaluation of the seller's digital 
content. 

FIG. 7 is a data flow diagram illustrating embodiments of 
the present invention with transactions similar to those 
illustrated in FIG. 5, in which the novel broker completes the 
transaction by releasing payment to the seller and releasing 55 
the digital content to the buyer at different times, despite the 
risk that the later release will be prevented after the first 
release is underway or completed. 

FIG. 8 is a data flow diagram illustrating embodiments of 
the present invention with transactions in which the seller go 
and the buyer each provide digital content to be released to 
the other after their approval ts given to the novel broker. 

FIG. 9 is a data flow diagram illustrating embodiments of 
the present invention with transactions in which the novel 
broker is used primarily or solely to provide samples of 65 
digital content, and hence does not necessarily participate in 
the transaction by releasing payment or by releasing goods. 
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FIG. 10 is a flowchart further illustrating techniques 
which may be used in the novel broker, separately or in 
combination, to provide buyers and/or sellers with samples 
of digital content. 

FIG. 11 is a diagram illustrating a configuration of com- 
puters and networks suitable for use according to the present 
invention. 

FIG. 12 is a diagram illustrating an architecture for an 
automatic broker according to the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

In describing methods, devices, signals, programs, 
products, and systems according to the invention, the mean- 
ing of several important terms is clarified, so the claims must 
be read with careful attention to these clarifications. Specific 
examples are given to illustrate aspects of the invention, but 
those of skill in the relevant art(s) will understand that other 
examples may also fall within the meaning of the terms 
used, and hence within the scope of one or more claims. 
Important terms may be defined, either explicitly or 
implicitly, here in the Detailed Description and/or elsewhere 
in the application file. 

In particular, an "embodiment" of the invention may be a 
system, an article of manufacture, a method, the product of 
a process, and/or a signal which configures a computer 
random access memory, disk, CD, DVD, or other computer- 
readable media 1110. In jurisdictions which permit it, such 
as some European jurisdictions, an embodiment may also be 
a computer program, provided it meets the novelty, 
inventiveness/nonobviousness, and other legal requirements 
of the jurisdiction. 

For convenience, reference is also made to sellers and 
buyers as "human parties" or "humans" to distinguish them 
from the automatic broker of the invention. But a buyer 
and/or seller may be any legal person, such as an individual, 
corporation, limited liability company, foundation, 
partnership, French "S.A.", German "GmbH", etc. Also, the 
broker is presumably programmed, built, or otherwise cre- 
ated and/or maintained by people according to teachings 
herein. Operation of the broker may be overseen by human 
administrators and driven by data and/or commands from 
human users. The broker may also be property of an 
individual, corporation, or other legal person. 
Networks, Computers, Software, Infrastructure 

Suitable networks for configuration and/or use as 
described here include one or more local area networks, 
wide area networks, metropolitan area networks, and/or 
"Internet" or IP networks such as the World Wide Web, a 
private Internet, a secure Internet, a value-added network, a 
virtual private network, an extranet, an intranet, or even 
standalone machines which communicate with other 
machines by physical transport of media (a so-called 
"sneakernet"). In particular, a suitable network may be 
formed from parts or entireties of two or more other 
networks, including networks using disparate hardware and 
network communication technologies. 

One suitable network includes a server and several cli- 
ents; other suitable networks may contain other combina- 
tions of servers, clients, and/or peer-to-peer nodes, and a 
given computer may function both as a client and as a server. 
Each network includes at least two computers such as the 
server and/or clients. A computer may be a workstation, 
laptop computer, disconnectable mobile computer, server, 
mainframe, cluster, so-called "network computer" or "thin 
client", personal digital assistant or other hand-held com- 



02/24/2003, EAST Version: 1.03.0002 



US 6,343 

9 

puting device, "smart" consumer electronics device or 
appliance, or a combination thereof. 

Each computer includes at least a processor and a 
memory; computers may also include various input devices 
and/or output devices. The processor may include a general s 
purpose device such as a 80x86, Pentium (mark of Intel), 
680x0, or other "off-the-shelf microprocessor. The proces- 
sor may include a special purpose processing device such as 
an ASIC, PAL, PLA, PLD, Field Programmable Gate Array, 
or other customized or programmable device. The memory 10 
may iaclude static RAM, dynamic RAM, flash memory, 
ROM, CD-ROM, disk, tape, magnetic, optical, or other 
computer storage medium. The input device(s) may include 
a keyboard, mouse, touch screen, light pen, tablet, 
microphone, sensor, or other hardware with accompanying 15 
firmware and/or software. The output device(s) may include 
a monitor or other display, printer, speech or text 
synthesizer, switch, signal line, or other hardware with 
accompanying firmware and/or software. 

The network may include communications or networking 20 
software such as the software available from Novell, 
Microsoft, Artisoft, and other vendors, and may operate 
using TCP/IP, SPX, IPX, and other protocols over twisted 
pair, coaxial, or optical fiber cables, telephone lines, 
satellites, microwave relays, modulated AC power lines, 25 
physical media transfer, and/or other data transmission 
"wires"' known to those of skill in the art. The network may 
encompass smaller networks and/or be connectable to other 
networks through a gateway or similar mechanism. 

At least one of the computers is capable of using a floppy 30 
drive, tape drive, optical drive, magneto-optical drive, or 
other means to read a storage medium. A suitable storage, 
medium includes a magnetic, optical, or other computer- 
readable storage device having a specific physical configu- 
ration. Suitable storage devices include floppy disks, hard 35 
disks, tape, CD-ROMs, DVDs, PROMs, random access 
memory, flash memory, and other computer system storage 
devices. The physical configuration represents data and 
instructions which cause the computer system to operate in 
a specific and predefined manner as described herein. Thus, 40 
the medium 1110 tangibly embodies a program, functions, 
and/or instructions that are executable by computers) 1100, 
1102, and/or 1104 to provide samples, escrow goods for 
bartering or for cash purchases, complete transactions, and/ 
or otherwise help facilitate transactions in digital and/or 45 
other goods or services substantially as described herein. 
Likewise, the "wires" and other data carriers and hard drives 
and memory may embody signals for facilitating transac- 
tions in digital and/or other goods or services substantially 
as described herein. 50 

Suitable software to assist in implementing the invention 
is readily provided by those of skill in the pertinent art(s) 
using the teachings presented here and programming lan- 
guages and tools such as Java, Pascal, C++, C, database 
languages, APIs, SDKs, assembly, firmware, microcode, 55 
and/or other languages and tools. Suitable signal formats 
may be embodied in analog or digital form, with or without 
error detection and/or correction bits, packet headers, net- 
work addresses in a specific format, and/or other supporting 
data readily provided by those of skill in the pertinent art(s). 60 

Much of the infrastructure that can be used according to 
the present invention is already available, such as: general 
purpose computers; computer programming tools and tech- 
niques; computer networks and networking technologies; 
digital storage media; authentication, access control, and 65 
other security tools and techniques provided by public keys, 
encryption, firewalls, and/or other means; bank transfers, 
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credit card processing, digital money, and other tools and 
techniques for making payments. Such existing technologies 
are not claimed by themselves. However, the present inven- 
tion uses existing infrastructure in new ways and adds 
incremental improvements to that infrastructure. 
Overview 

The inventive approach shown in FIG. 5 does bear some 
resemblance to the conventional approach shown in FIG. 4. 
As in FIG. 4, the transaction is between at least one seller 
500 and at least one buyer 502, and if all goes well then the 
seller receives payment and the buyer receives goods. 

However, in any given embodiment of the invention, there 
are one or more significant differences between the 
invention, on the one hand, and conventional tools or 
techniques on the other hand. These differences may include 
the parties participating, the goods involved, the samples 
involved, the path taken by the goods, the path taken by the 
payment, and the type and level of trust required. Although 
they are related and may be combined in inventive 
embodiments, we consider each of these in turn below. 

For clarity of illustration, negotiations between parties are 
not shown in FIG. 5 or subsequent Figures, but it should be 
understood that such negotiations may occur at zero or more 
points during a given transaction according to the present 
invention. Also, transactions according to the invention may 
involve more than one buyer and/or more than one seller; for 
clarity of illustration, only a single seller 500 and a single 
buyer 502 are shown in the Figures. 
Parties 

One difference between the conventional approach illus- 
trated in FIG. 4 and the inventive approach shown in FIG. 
5 is the presence of an automatic broker 504. The automatic 
broker 504 is identified in the priority application Serial No. 
60/134,383 as "Q", and is identified herein as "Q", "the 
broker", "broker 504", "automatic broke r", etc. In some 
embodiments, the automatic broker 504 supplements or 
replaces the conventional agent A discussed in the Technical 
Background section above by escrowing goods, completing 
transactions, and so on. As indicated in FIG. 4, conventional 
agent A is an attorney, escrow firm, or other person or 
institution known before the present invention. In other 
embodiments, the broker 504 is used by an agent A or 
another transaction party to generate samples. 

The automatic broker Q may be implemented as an 
automatic impartial broker in computer hardware and/or 
software according to the invention. For instance, Q may be 
embodied in novel software running on general-purpose 
hardware. Q could also involve novel hardware. The inven- 
tion is not limited to Q but also includes related signals, and 
methods using Q such as business methods for transacting 
digital content sales. Q's impartiality is preferably reason- 
ably protected through encryption, certification, anti-virus 
protection, and like measures, to prevent intervention by 
untrustworthy parties. Untrustworthy parties are those who 
would unfairly take advantage of others* trust in Q. For 
instance, an untrustworthy party might try to take unfair 
advantage of others' reliance on the assumption that Q will 
complete the transaction if and only if the buyer(s) and the 
sellers) expressly advise Q of their consent to such comple- 
tion. 

When properly implemented, the automatic broker Q is 
not subject to temptation. Thus, if the broker Q is pro- 
grammed by persons having trustworthy intent and adequate 
technical skills, Q will be impartial in the sense that it may 
be entrusted with transaction facilitation tasks with fewer 
trust-related risks than in some conventional approaches. 
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Goods 

In a conventional transaction like that shown in FIG. 4, 
the goods are not necessarily digital. By contrast, transac- 
tions with the automatic broker 504 involve at least some 
digital goods 506; non-digital goods may or may not also be 5 
involved. In some embodiments, the goods 506 are digital in 
the sense that they include digital content such as bits, files, 
databases, etc. which are placed in escrow with the broker 
504, to be released by the broker 504 as part of transaction 
completion. In some embodiments, the goods 506 are digital 10 
in the sense that their digital content serves as an original 
(i.e., an initial copy) from which the broker 504 creates 
samples 508 as discussed herein. 

In some transactions, the digital goods 506 are the only 
goods that are subject to the transaction at hand. In other 15 
transactions, rights in non-digital goods may also be 
transferred, as when a seller provides both a digital technical 
description of some chemical composition, and physical 
pieces of that composition for spectrographs or other physi- 
cal inspection. Of course, other non-digital goods may be 20 
treated similarly, as when samples are extracted or test data 
is provided on alloys, minerals, agricultural products, and so 
on. 

In some transactions, the digital goods 506 represent or 
replicate non-digital goods. For instance, the digital goods 25 
could include seismic records indicating the nature and 
extent of petrochemical deposits; satellite images; or instru- 
ment readings or traces, including, for instance, output from 
medical imaging devices such as CAT or NMR scans, from 
chemical analysis tools such as gas spectrometers, from 30 
physics instruments such as electron microscopes, or from 
other instruments whose data can be checked by the buyer 
for internal consistency and whose data provide the buyer 
with pertinent information about the physical goods. 
Samples 35 

Conventional transactions involve no samples at all, or 
involve samples of conventional types. Conventionally, 
samples are provided by sellers in the form of physical 
pieces of the goods, as when part of a fluid good is siphoned 
off to be tested, or when one free pen or other specimen of 40 
a mass produced item is provided to encourage purchase of 
additional copies. Conventional samples of software are 
often provided in the form of "demo" software which runs 
but has only a subset of the functions of the regular product 
and/or has a built-in limit on the duration of use and/or the 45 
total number of uses. Although catalog descriptions and 
images are not the same as samples of the described and 
depicted items, conventional catalog entries are used to 
convey product information and encourage purchase, which 
are also common goals when providing demo versions, 50 
specimens, or other conventional samples. 

By contrast, samples 508 are provided by the broker 504. 
Unlike transactions in which the seller provides the sample 
directly to the buyer or provides the agent A with the sample 
to be given to buyers, in some embodiments of the invention 55 
the seller 500 does not directly generate the sample 508. 
Instead, the automatic broker 504 generates the sample. 
Indeed, in some transactions, the seller 500 never receives a 
copy of the sample 508 from the broker 504. 

In addition, embodiments of the invention permit samples 60 
508 to be more than "siphoned off" specimens. Content for 
a sample 508 may be extracted from the content of the goods 
506, but the extraction can be performed in various ways, 
and it may depend on the type of digital good 506 involved. 
Content for a sample 508 may also be obtained by other 65 
techniques, such as by distorting or enhancing the content of 
the goods 506. 



Path of the Goods and the Payment 

In some conventional transactions, like those illustrated in 
FIG. 4, goods are shipped directly from the seller to the 
buyer. This may be done in transactions according to the 
present invention. However, digital goods 506 can also be 
escrowed with the automatic broker 504, to be released 
automatically to the buyer 502 after payment is made. 

Likewise, in conventional transactions payment may be 
sent directly from the buyer to the seller. This may also be 
done in transactions according to the present invention. 
However, a digital payment 510 can also be escrowed with 
the automatic broker 504, to be released automatically to the 
seller 500 after the goods 506 are provided. 

In particular, FIG. 5 illustrates an embodiment of the 
invention in which neither the goods nor the payment are 
provided directly by one of the human parties to the other. 
Instead, the goods 506 and the payment 510 are each 
escrowed with the automatic broker 504. Only after it 
receives both the goods 506 and the payment 510 does the 
broker 504 release them to the other party (by sending 512 
the payment to the seller 500 and sending 514 a copy of the 
digital goods 506 to the buyer 502). This approach requires 
the seller 500 and the buyer 502 to each trust the automatic , 
broker 504, rather than asking them to trust each other. For 
instance, the seller 500 need not worry that the buyer 502 
will receive a useable copy of the goods 506 without the 
seller 500 being paid, and the buyer 502 need not worry that 
the seller 500 will receive payment without the buyer 502 
receiving a useable copy of the goods 506. 
Trust Issues 

As noted, some embodiments of the invention shift the 
trust required from trust in the other party to trust in the 
automatic broker. This may facilitate transactions that would 
otherwise not occur. When properly implemented and 
administered, the automatic broker is preferably an impartial 
entity. That is, the broker's behavior does not unfairly favor 
any human party over any other human party in the trans- 
action. 

Moreover, people may perceive the automatic broker as 
more trustworthy than human agents, because machines are 
usually not subject to human emotions such as greed, fear, 
or hatred that sometimes skew transactions between people. 
This does not mean a severely mechanistic interface, such as 
a sequence of forms, would necessarily be best. People 
sometimes reveal confidences or otherwise place trust in 
programs that mimic people, such as the ELIZA program, so 
a natural language interface could also be used in embodi- 
ments of the automatic broker, 

Alegally binding confidentiality or non-disclosure agree- 
ment is used in some embodiments of the invention, to 
assure sellers that the buyer will not disclose confidential 
sample contents, for instance. Unlike conventional 
transactions, however, the invention provides a way for 
prospective buyers to inspect digital goods without neces- 
sarily obtaining a complete and useable copy of those goods. 

Instead, the samples 508 permit sellers to provide buyers 
with enough information to permit inspections of quality 
and/or extent without forcing sellers to rely solely on legal 
means (e.g. contract or copyright law) or business ethics to 
prevent buyers from unauthorized use of easily reproduced 
digital goods. This encourages sellers to make goods avail- 
able for inspection, which facilitates transactions. Some 
embodiments of the invention also remove the selection of 
samples 508 from the control of the seller. This encourages 
buyers to rely on the samples as accurate guides to the 
content of the digital goods 506, which also facilitates 
transactions. In short, the invention reduces or eliminates 
questions of trust which inhibit transactions in digital con- 
tent. 
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FIG. 5 is not comprehensive. To further illustrate the 
invention, we now consider some additional examples, using 
both the notation introduced earlier and additional Figures. 
The Figures and the notational examples do not necessarily 
correspond precisely with each other as representations of 5 
the invention. That is, the Figures illustrate inventive 
embodiments or aspects thereof which are not called out 
expressly in the notation examples, and vice versa. Also, 
some embodiments of the present invention mix elements 
which are set forth in the Figures with elements set forth in 10 
the notational examples. 
Additional Goods-for-Payment Transactions 

FIG. 6 illustrates an embodiment similar to that shown in 
FIG. 5, with the addition of a step transmitting the samples 
508 to the seller. That is, in this embodiment the seller 500 15 
receives a copy of the samples that are created by the broker 
504 and then provided by the broker 504 to the buyer 502 for 
inspection. 

By contrast, the seller in FIG. 5 only obtains a copy of the 
samples 508 if the buyer sends it one. The seller does not 20 
provide the samples to the broker 504 for forwarding (the 
broker creates the samples), and the broker 504 does not 
provide the seller with a copy of the samples the broker 
creates. 

In conventional approaches, a seller of digital goods has 25 
the opportunity to inspect copy of the samples that the buyer 
receives, either because the seller creates the samples itself 
or because the seller knows in advance what techniques will 
be used to create the samples. For instance, a seller of 
images may itself conventionally create thumbnail samples, 30 
or the seller may conventionally use software tools which 
will create thumbnail samples on the seller's behalf using 
techniques whose details are not necessarily understood by 
the seller but whose results are readily predicted by the 
seller. 35 

In the embodiment shown in FIG. 6, by contrast, the 
broker 504 creates the samples 508 using techniques whose 
results are not necessarily known ahead of time to the seller 
500. Because the seller 500 cannot easily predict what 
algorithms will be used to create the samples from the goods 40 
506 provided to the broker 504 by the seller, the invention 
can make it difficult or impossible for the seller to trick the 
broker into sending the buyer 502 samples that are not 
accurate guides to the nature and extent of the digital goods. 

The samples 508 may be provided to the seller for one or 45 
more purposes. For instance, the techniques used to create 
the samples may be challenged by the seller, in which case 
the buyer and seller may agree that the broker should 
produce a second (or third, fourth, etc.) sample using a 
different technique. Note that the broker 504 preferably uses 50 
a subsequent sampling technique which produces a subse- 
quent sample that cannot be combined with the previous 
sample(s) to obtain a complete and useable copy of the 
goods. Sampling should allow inspection without permitting 
full use of the goods. 55 

FIG. 7 illustrates embodiments in which the automatic 
broker 504 releases 514 the goods at a substantially different 
time than it releases 512 the payment. In FIG. 7, the goods 
506 are released before the payment 510, but other embodi- 
ments similarly release the payment 510 before releasing the 60 
goods 506. Either approach creates a risk that the broker 504 
will be unable to complete the transaction. For instance, the 
broker 504 or the network might be attacked after the 
payment 510 has been transmitted but before the goods 506 
are transmitted. Nonetheless, releasing the payment 510 and 65 
the goods 506 at different times may be desired for 
convenience, by mutual agreement of the parties, to take 
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advantage of network bandwidth (goods will generally be 
larger than payments, in terms of bandwidth required for 
transmission), and/or for other reasons. 
Barter Transactions 

FIG. 8 illustrates barter embodiments in which the buyer 
and seller each provide the other with digital goods, as 
opposed to situations in which the seller provides digital 
goods and the buyer provides digital cash or similar liquid 
payment. The seller places 800 its digital goods in escrow 
with the broker 504, which obtains samples thereof and then 
sends 802 the samples to the buyer. Likewise, the buyer 
places 804 its digital goods in escrow with the broker 504, 
which obtains samples that it sends 806 to the seller. At this 
point, the broker 504 has the digital content that was 
submitted by each party 500, 502, and each party 500, 502 
has samples of the other's digital content. The samples were 
preferably produced by techniques not chosen by the parties, 
but selected instead by the broker 504, so that each party can 
rely on the samples as representative of the goods being 
proposed by the other party for the exchange. 

If each party 500, 502 is satisfied with the other's goods, 
as represented by the sample it received from the broker 504, 
then each party gives its approval to the broker 504. The 
broker 504 then completes the transaction by releasing 812, 
814 each party's goods to the other party. 

If either party is unsatisfied with the samples or wishes to 
cancel the deal for some other reason, it can withhold its 
approval, and the transaction will time out without being 
completed. Alternately, a party can expressly cancel the 
transaction. In either case, the broker deletes the escrowed 
goods. The broker 504 may also overwrite the hard disk, 
RAM, and/or other memory that held the parties' digital 
content, using an electronic "shredding" algorithm such as 
that employed by various known products for military and 
other security purposes. 

Barter transactions are also illustrated in the following 
method for facilitating barter transactions involving digital 
content, the digital content provided by at least two parties, 
the method comprising the steps of: 

receiving from a first party a copy of first digital content 
and escrowing that first digital content; 

receiving from a second party a copy of second digital 
content and escrowing that second digital content; 

determining an approval exists to release the first digital 
content to the second party; 

determining an approval exists to release the second 
digital content to the first party; 

releasing the first digital content to the second party; and 

releasing the second digital content to the first party. 

In some embodiments, at least one of the determining 
steps comprises receiving an approval from the party that 
provided the digital content being approved for release. In 
others, lack of disapproval is taken as approval, so at least 
one of the determining steps comprises timing out after no 
cancellation is received from the party that provided the 
digital content being approved for release. 

In some embodiments the method further comprises the 
steps of creating a sample of digital content, and sending the 
sample to at least one of the parties prior to at least one of 
the determining steps. If the digital content includes an 
image, for instance, then the step of creating a sample could 
create a thumbnail of the image. Thus, the exchange may be 
based on an inspection by one or more parties of samples 
taken from the goods proposed by other parties for 
exchange. 

More generally, in these and other transactions according 
to the invention each party provides the other with compo- 
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nents in the form of liquid payment, digital goods, non- 
digital goods, and/or legally binding promises, in varying 
mixtures, including mixtures that omit one or more such 
components. To give just two of the many possible 
examples, rather than exchanging payment for goods, the 
parties could exchange goods for goods (per FIG. 8), or they 
could exchange payment for a time-limited option on the 
goods. That is, a "sale" of digital goods includes a lease, or 
an exchange for other goods or services, or legal promises, 
or liquid payment. This makes the terms "buyer" and 
"seller" broader than would otherwise be the case, since a 
"buyer" may receive payment and a "seller" may receive 
goods, but the terms are convenient so we use them none- 
theless. Also, barter transactions may provide payment as 
well as goods, and payment transactions may provide goods 
as well as payment. 
Samples vs. Transactions 

FIG. 9 illustrates embodiments of the invention which 
facilitate transactions but do not necessarily include any 
particular transaction completion. In these situations the 
seller 500 does not necessarily know the identity of the 
prospective buyer 502. Indeed, in some cases, the seller does 
not even know whether there presently are any prospective 
buyers. Rather, these embodiments employ the novel sam- 
pling aspects of the invention to make samples available at 
web sites, FTP sites, bulletin boards, and/or other locations 
that are accessible to some population that may include one 
or more buyers. 

That is, the seller 500 provides 900 a copy of its digital 
content to the broker 504. The broker 504 then obtains 902 
one or more samples, by using extraction, distortion, 
enhancement, or a combination thereof on the provided 
digital content, as taught herein. Then the broker provides 
904 the samples by placing copies of them on the web site, 
FTP site, and/or bulletin board to permit access by prospec- 
tive buyers 502. 

In one alternative, the seller uses the broker 504 to obtain 
the samples and does not necessarily rely on the broker to 
complete the transaction by transmission of goods from the 
broker 504 to the buyer 502. Indeed, in some embodiments, 
the goods are not retained by the broker 504, but are instead 
made available to the broker 504 by the seller 500 merely to 
permit the broker to create the samples, which the broker 
504 then gives to the seller. The seller 500 then proceeds as 
it sees fit, such as by requesting that the broker create 
different samples using different techniques, and/or by pro- 
viding the samples directly to a prospective buyer rather 45 
than going through the broker 504 to pursue or complete a 
transaction. 

Additional Transaction Examples 

Turning now from the Figures back to the notational 
examples, consider the following transaction T4Q involving 
seller S, buyer B, and the novel computerized element Q 504 
in generally the position taken earlier by the human agent A. 
This transaction was described in the priority application 
No. 60/134,383 and is repeated here for completeness and 
convenience: 

1. ?(S-D->B) || ?(S-M->B) 

2. ?(S<-N->B) // could also precede (n), or precede and 
follow, or overlap 

3. Q<-$-B // novel software receives money from buyer 
and holds or escrows it 

4. S<-OK-Q // software Q confirms to S that Q has 
payment 

5. S-G->B 

6. S<-OK-B || Q<-OK-B // B OK's goods and OK's 
payment completion 

7. S<-$-Q // Q releases finds to S 
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When properly programmed and operating, Q can be 
trusted by buyer B not to abscond with the payment $ after 
step (3). B can also trust Q to perform step (7) when, and 
only when, approval is given to Q by B in step (6). Likewise, 
Q can be trusted by S not to take the payment and disappear 
after step (3), and can likewise be trusted not to deny 
receiving the payment (no step (4)). 

A variation T4Q 1 involves transferring the goods to Q and 
then releasing them; the trust issue analysis is similar to that 
above for T4N: 

1. ?(S-D->B) || ?(S-M->B) 

2. ?(S<-N->B) // could also precede (n), or precede and 
follow, or overlap 

3. S-G->Q // novel software receives goods from seller 
and holds or escrows them 

4. Q-OK->B // software Q confirms to B that Q has goods 

5. S<-$-B 

6. S-OK->Q || S-OK->B // S OK's payment and OK's 
goods transfer to B 

7. Q-G->B // Q releases goods to B 

Note that Q could "have" the goods and/or "release" the 
goods either by having proof in digital form from a bank or 
government agency or highly trusted third party that the 
goods are under Q's control, or by having physical oversight 
of the goods when the goods are digital in nature. That is, Q 
could know the storage location of the digital goods and 
have control (through encryption, access control lists, 
firewalls, groups, permissions, tokens, and/or other familiar 
access control tools and techniques) of those digital con- 
tents. 

A transaction T5Q involving novel automatic broker Q 
goes like this: 

1. ?(S-D->B) || ?(S-M->B) 

2. ?(S<-N->B) // could also precede (n), or precede and 
follow, or overlap 

3. (Q<-$-B || S-G->Q) // broker receives money from 
buyer and goods from seller 

4. (Q-OK->B || S<-OK-Q) // broker confirms goods & 
payment OK and in hand 

5. (Q-G->B || S<-$-Q) // broker releases goods to buyer & 
payment to seller 

Again, Q can be both trustworthy and trusted if properly 
implemented. Q would not intentionally retain illegal pos- 
session of both the goods and the money after step (3). Q 
would not intentionally misrepresent the amount or quality 
or receipt of the goods and/or money in step (4). Q would not 
intentionally defraud a party by releasing an item (goods or 
payment) to one party without releasing the corresponding 
item to the other party in step (5). Q would be programmed 
to be impartial, and programmed to protect that impartiality 
from being overridden, regardless of whether S, B, or some 
third party is behind the override effort. 

Impartiality of software in the context of a business 
exchange has been recognized as valuable, at least 
implicitly, by the creators of the cyberSettle.com web site. 
The software available through that site accepts settlement 
offers, holds them confidential, compares them, and 
announces a settlement if they fall within a predetermined 
distance of each other. However, cyberSettle.com apparently 
does not broker transactions between buyers and sellers of 
goods, much less between buyers and sellers of digital 
goods. It is also believed by the inventor that cyberSettle- 
.com does not teach the present invention's tools and tech- 
niques for obtaining and/or using samples of digital content. 
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In addition to the broker, the seller(s), and the buyer(s), a 
transaction according to the invention may include other 
entities. For instance, A transaction T7 uses both Q and a 
third party financial institution F, such as an electronic 
banking facility: 5 

1. ?(S-D->B) 

2. ?(S<-N->B) // could also precede (n), or precede and 
follow, or overlap 

3. S-G->Q 

4. Q-X->B || ?(S<-X-Q) // S might get X so S knows basis io 
for B's view of G 

5. ?(S<-N->B) // parties might renegotiate after B views 
X 

6. (F<-$-B) // B will pay this much for G based on sample 

X 35 

7. (Q<-OK->F) // Q verifies funds transfer from B with F; 
Q OK's F paying S 

8. (Q-G->B || S<-$-F) // broker releases goods to buyer & 
F pays seller 

Note that in any or all of the various transactions using Q 20 
and/or X, the parties S and B might prefer to remain 
anonymous (subject to any applicable legal requirements). 
Anonymous remailers, anonymous funds transfers, anony- 
mous logins, and/or email aliases could be used. This 
anonymity reduces the risk of being overpowered by the 25 
other party, such as the risk in transaction 13. It may also 
promote transactions between parties that would otherwise 
not deal with each other for historic reasons that have little 
or nothing to do with the particular goods in question. 

Note that Q (and Q with F) can reduce trust issues in 30 
transactions, but cannot entirely eliminate them. For 
instance, in some contexts, knowledge of the number of 
copies of the digital content may be important. However, the 
inventive tools and techniques cannot guarantee that the 
copy of digital goods G sold to B is unique. S may have 35 
retained a copy and/or sold another copy to some other buyer 
B\ 

Digital and Other Goods 

Suitable digital content and/or digital goods include 
executable software; software source code; email and other 40 
mailing lists; databases of various types and formats, such as 
relational, object-oriented, or hierarchical databases; CAD 
files; scanned documents; word processor or spreadsheet 
documents; web pages; scripts; digital or digitized 
photographs, video, sounds; multimedia presentations; 45 
patent applications, design documents, and other scientific 
and technical information in computerized form; multimedia 
presentations and courses; digital images (still, user- 
navigable 360-degree, and video); digital sounds; digital 
movies and other entertainment content; and a wide variety 50 
of other digital content. The collection of suitable digital 
content may well grow over time. For instance, in addition 
to sounds and images, it is also apparently possible to 
digitally encode smells. One could thus expect efforts to 
digitally encode tastes, if such efforts are not already under- 55 
way. 

The digital content may be in plain form, or the user or 
other entities or agents (e.g., system software) may have 
encrypted and/or compressed the digital content. The result 
of encrypting and/or compressing digital content is still 60 
digital content. 

Securities, stocks, bonds, futures, notes, mortgages, and 
such financial instruments are not "digital goods." However, 
one or more such items may serve as "payment" in an 
embodiment of the invention that requires a payment. 65 

As used herein, "digital" includes both content that was 
originally generated in digital form and content that was 
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converted (e.g., digitized) into a digital form from a non- 
digital form via scanning, conventional sampling, and/or 
another process. 

The terms "digital content" and "digital goods" are 
equivalent, at least from the perspective of obtaining 
samples, releasing content, and similar operations per- 
formed by the broker 504. Using both terms provides a more 
accurate impression of the invention's scope. Using "digital 
goods" alone might give the mistaken impression that works 
of art or scientific research cannot be exchanged according 
to the present invention, while using "digital content" alone 
might give the mistaken impression that only works from 
so-called "content providers" can be thus exchanged. 
Obtaining and Using Samples 

When the goods involved are digital, the automatic broker 
Q can reduce risks arising from descriptions and/or samples 
that are not representative of the actual goods. The term 
"sample" has special meaning when used in reference to 
certain embodiments of the present invention, namely, those 
in which the sample is characterized in that its content is not 
predicted by the seller, whereby the sample contains useful 
information about the digital content without containing a 
complete and accurate copy of the digital content In other 
embodiments, "sample" may refer to conventional samples 
(obtained by conventional techniques such as creating a 
thumbnail of an image or quoting an excerpt from a text) or 
"sample" may refer to samples obtained by novel techniques 
like those described herein. 

As illustrated in FIG. 10, with respect to the invention, 
sampling techniques 902 include selecting 1002 a subset of 
existing data, distorting 1004 data, and/or enhancing 1006 a 
data set. That is, a novel sample X may be created by 
selecting content from digital goods 900 in a previously 
unknown way, by distorting content from digital goods 900, 
and/or by adding specified content to digital goods 900. As 
noted, the digital goods 900 may be supplied to the broker 
504 by one or more sellers and/or buyers. A transaction 
involving the samples may be completed by the broker 504 
as intermediary, or it may be completed by the parties 
without further use of the broker 504 once the broker 
provides the sample(s). 

Note that conventional sampling by selecting a portion of 
non-digital goods is well-known in conventional transac- 
tions. Embodiments of the present invention provide novel 
samples, novel transactional uses of samples extracted from 
digital data by conventional techniques, and/or novel tech- 
niques for obtaining samples from digital goods. For 
instance, conventional tools and techniques for string 
manipulation, search/replace, numerical calculations, flow 
control, lookup tables, bit-shifting, user-defined functions, 
and callable DLLs may be used according to the present 
invention to create samples whose content is not predicted 
by a seller and is therefore less subject to manipulation by 
the seller. 

To illustrate the use of samples, consider the transaction 
T6Q described by the notation below. A sample X is 
extracted from the digital goods by the broker Q in a manner 
which is not necessarily known beforehand by seller S and 
which is selected to make the sample X a poor or worthless 
substitute for the sampled goods G themselves: 

1. ?(S-D->B) 

2. ?(S<-N->B) // could also precede (n), or precede and 
follow, or overlap 

3. S-G->Q 

4. Q-X->B II ?(S<-X-Q) // S might get X so S knows basis 
for B's view of G 

5. ?(S<-N->B) // parties might renegotiate after B views 
X 
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6. (Q<-$-B) // B will pay this much for G based on sample 
X 

7, (Q-G->B || S<-$-Q) // broker releases goods to buyer & 
payment to seller 

The tools and techniques used to extract samples such as s 
X may vary. For instance, if digital content includes an email 
list in ASCII text, a sample could contain every fourth 
character (or Nth character, with a small N>1). This partial 
copy allows a buyer to verify the lack of duplicate entries in 
the list, the geographic area covered by the list, the number 10 
of list entries, and so forth, without simply giving the 
complete list to the buyer in useable form before the buyer 
pays for the complete list. Samples may be free, or they may 
be given in exchange for some item of value (e.g., cash, 
goods, services, or samples of other goods). 15 

Similar steps could be taken with source code and other 
human-readable documents to make samples helpful to 
buyers without leaving sellers too vulnerable. Sampling 902 
allows the prospective buyer to evaluate the credibility of 
the seller's claims about the digital goods without fully 20 
revealing the content of the goods and thereby making 
payment unnecessary if the buyer is not bound in fact by 
contract, copyright, ethics, or other constraints that encour- 
age or ensure payment. 

Care is preferably taken to prevent a seller S from 25 
intentionally providing damaged or incomplete goods by 
anticipating the sampling technique used to create X. For 
instance, suppose a mailing list is represented by the seller 
to contain several thousand different entries, but this is not 
actually the case. If the seller knows that samples of the list 30 
will be produced by extracting every fiftieth entry, then the 
seller can inflate the list to fifty times its valid size by 
repeating each valid entry an additional forty-nine times. 
Sampling will indicate that the list contains much more valid 
data than is actually the case. If the buyer and seller are in 35 
separate legal jurisdictions, are dealing with one another 
anonymously, or the buyer's legal and business recourse is 
otherwise limited, then the seller could gain an unfair 
advantage from the buyer's reliance on the sample. 

To avoid this and similar situations, the seller should not 40 
know what sampling technique(s) will be used. It should 
also be difficult or impossible to reconstruct the original 
digital content from the sample if the sampling technique is 
not known, and in cases involving partial copies, even if the 
technique is known. 45 

If the digital content includes photos, then the samples 
might be thumbnails, or "pixelated" (adjacent pixels 
averaged) images, or images that include only some color 
components or lack an alpha channel. Similar techniques for 
creating 1002 partial copies could be used with digital 50 
sounds, such as sampling at fixed intervals, or providing 
some but not all channels of a multi-channel digital audio 
recording. 

To distort 1004 and/or burden 1106 the content during 
sampling, X could be watermarked or otherwise marked 55 
through steganographic techniques. Steps could also be 
taken to prevent use or reproduction of a sample X, such as 
using a Java applet to display X while preventing a copy of 
X from being made on buyer B's hard disk or printed. A 
copy of the original digital content could also be distorted 60 
1004 by shifting colors in images, shifting frequency in 
images or sounds, adding noise to images or sounds or other 
content, or reordering the order of words or sentences in text. 

Note that the sampling technique selection, like the appli- 
cation of the technique by Q, can be partially or fully 65 
automated. If a lookup of the filename extension, confirma- 
tion of a header signature or other pattern, or some other 



programmed test identifies the data type, automatic selection 
by Q can be used. Likewise, a given implementation of Q 
may be limited to a single data type, such as "ASCII prose" 
or "XML text" or "patent applications in Microsoft Word 
format". Alternately, the parties S and B may agree on a 
general class of sampling techniques and/or inform Q of the 
data type. 

Tailoring the sampling technique to the type of digital 
content may be convenient in some cases, and critical in 
others. This depends in part on the categories used to define 
content types. For instance, an ASCII mailing list and an 
ASCII word processor file might both be categorized as 
"ASCII text", and sampling could be done by deleting every 
Nth (with N=3, 4, or 5, for example) character. Alternately, 
"mailing list in ASCII text form" and "documents other than 
mailing lists, in ASCII text form" might be separate data 
categories subject to different sampling techniques. For 
instance, the mailing list might be parsed and the sample be 
produced 1002 by deleting all the recipient names and 
numeric portions of street addresses while leaving the postal 
codes. Non-mailing list documents could still be sampled, 
very quickly and without significant parsing, by deleting 
every Nth character. 

Content categories can be defined by defaults pro- 
grammed into the broker Q, by definitions given by seller 
and/or buyer, or by a combination of these sources. File 
extensions, keywords, and other familiar indicators can be 
used to identify the formats of inputs to Q for sampling, and 
thus to identify in at least some cases the likely nature of the 
digital content and the type of sampling techniques to use. 

Familiar techniques such as timestamps, checksums, 
secure digital envelopes, watermarks, and/or digital signa- 
tures can be used to permit buyers and/or sellers to authen- 
ticate the samples they receive, to ensure that the samples 
arrive intact as produced 902 by the broker. For instance, 
watermarks and/or digital signatures may be embedded in 
the sample (or equivalently, in a digital envelope containing 
the sample) as authentication information, thereby permit- 
ting authentication which verifies that the automatic broker 
tool is the source of the sample. 

More generally, encryption, passwords, public keys, 
tokens, Secure Sockets Layer transmissions, and other 
familiar tools and techniques can be used to provide secure 
communications between the parties and the broker 504, 
and/or between the parties 500, 502 themselves, to protect 
samples, digital goods, payment information, and other data. 
Authentication may also be required of the seller and/or the 
buyer in some embodiments. 

Note that in embodiments that use the broker 504 only to 
create the samples, the broker 504 might run at the seller's 
site, making an SSL or other secure network connection 
between broker and seller unnecessary. If the seller or an 
agent A will provide the samples to the buyer, then the 
broker 504 preferably digitally signs or watermarks the 
samples, to permit authentication of the broker 504 as the 
source of the samples. 

To illustrate the sampling step 902 further, assume the 
following source code is part of the digital content which is 
offered for "sale" (that is, in an exchange for cash payment 
or for other goods or services) in a particular transaction: 
flen: Integer; 
Begin 

With Database A .Tag_Ptr[Ptr]%Database A do 
Begin 

FiUchar(Tag_JLine[l],80/ '); 
Tag_Line[0] := chr(80); 

If (length(Group)>0) and (length(Group)<5) then 
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Move(Group[l],Tag_Line[2],length(Group)); 
If (length(Tag_Id)>0) and (length(Tag_Jd)<ll) then 
Move(Tag_ / ^ 1] ^ I3 _line[7],length(Tag_Id)); 

If (length(Tag_Desc)>0) and (length(Tag_Desc)<31) 
then 

Move(Tag_Desc[l],Tag_Line[18],length(Tag„ 
Desc)); 

If Cur__State in [0 . . . 16] then 
Begin 

Textcolor(Colors[Cur_State]); 
Move(State[Cur_State],Ta&__Line[49],6); 
End; 

End; 

End; 15 

Some sampling techniques create 1002 a sample X which 
is a partial copy of the original copy of the source code. In 
the following example, the sample is created 1002 by 
removing all array indices and any other characters that 
appear between matching square braces [ and ], so the 2 o 
sample X looks like this: 
flen: Integer; 
Begin 

With DatabaseMag_Ptr[ ]%Database" do 

Begin 25 
Fillchar(Tag_Line[ ],80/ 
Tag_line[ ] :» chr (80); 

If (length(Group)>0) and (length(Group)<5) then 
Move(Group[ ],Tag__Line[ ],length(Group)); 

If (length(Tag_Id)>0) and (length(Tag_Jd)<ll) then 
Move(Ta & _Jd[ ],Tag__Line[ ],length(Tag_Jd)); 

If (length(Tag__Desc)>0) and (length(Tag_Desc)<31) 
then 

Move(Tag_JDesc[ ],Tag_Iine[ ],length(Tag_Desc)); 35 

If Cur_State in [ ] then 
Begin 

Textcolor(Colors[ ]); 
Move(State[ ],Tag_Line[ ],6); 

End; 40 
End; 
End; 

Some sampling techniques create a sample X which is a 
partial copy of the original copy of the source code and is 
also distorted 1004. In the following example, the sample is 45 
created by replacing every fifth character by the character 
"4" (that is, by distorting every fifth character into a "4") so 
the sample X looks like this: 
flen4 Int4ger;4Begi4 

Wit4 Dat4base4.Tag4Ptr[4tr]~4Data4ase A 4do 50 
4egin4 Fil4char4Tag_4ine[4],804' ')4 
Ta4_Lin4[0] 4-ch4(80)4 

If4(len4th(G4oup)40) a4d (!4ngth4Grou4)<5)4then4 
Mo4e(Gr4up[14,Tag4Line42],14ngth4Grou4)); 
4If (4engt4(Tag4Id)>4) an4 (le4gth(4ag_J4)<114 the4 

M4ve(T4g_Id41],T4g_Li4e[7]41eng4h(Ta4 _Jd)4; 
14 (le4gth(4ag_D4sc)>4) an4 (le4gth(4ag_D4sc)<41) t4en 
4Move4Tag_4esc[4],Ta4_Un4[18]41eng4h(Ta4_Des4)); 
41f C4r_St4te i4 [0.416] 4hen 
4Beg4n 

4extc41or(4olor4[Cur4Stat4]); 
4 Mov4(Sta4e[Cu4_Sta4e],T4g_Ii4e[494,6);4 En4; 
E4d; 

E4d; 65 

Sampling techniques may sometimes be characterized in 
more than one way. For instance, the first sampling 
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approach, which removed characters found between square 
brackets, could also be characterized as an approach that 
distorts the characters between square brackets into nonex- 
istence. 

Another sampling technique creates 1002, 1004 a sample 
X which is a partial and distorted copy of the original copy 
of the source code by replacing every other numeric char- 
acter by the character "0", so the sample X looks like this: 
flen: Integer; 
Begin 

With Database'\Tag_Ptr[Ptr]%Database' 1 do 
Begin 

FiUchar(Tag_Line[l],0O ) < '); 
Tag Line[0] > chr(80); 

If (length(Group)>0) and (length(Group)<0) then 
Move(Group[l],Tag_Line[0],length(Group)); 

If (Iength(Tag_Id)>0) and (length(Tag_Id)<01) then 
Move(Tag_Id[0],Tag Line[7],length(Ta&_Id)); 

If (length(Tag_Desc)>0) and (length(Tag_Desc)<30) 
then 

Move(Tag_Desc[l],Tag_Line[08],kngth(Tag_ 
Desc)); 

If Cur_State in [0 . . . 10] then 
Begin 

Textcolor(Colors[Cur_StateJ); 

Move(State[Cur_State],Tag_Line[40],6); 

End; 

End; 
End; 

Source code is just one example of digital content that can 
be sampled 902. Non-textual digital content can also be 
sampled, as when image pixels, image voxels, or discrete 
elements of a digital sound recording are omitted or dis- 
torted. 

As another example of digital content which is textual, but 
is not source code, consider the following excerpt from U.S. 
Pat. No. 3,999,789: 

Bearing 100 supports the tailpiece driver 102 that extends 
from key lock 70. This tailpiece 102 thus extends 
through the matching opening in security dead bolt 
swivel 72, through bearing 100, through elongated 
vertical slot 98 of slide 90, through matching opening 
96a in driven cam 96, and into a matching opening in 
turnpiece 68, all as shown in FIG. 3. Therefore, rotation 
of the cylinder lock and tailpiece 102 by a key 71 will 
rotate dead bolt swivel 72 to extend or retract dead bolt 
58, depending upon the direction of rotation, and will 
also rotate cam 96 and turnpiece 68. Likewise, rotation 
of turnpiece 68 will rotate tailpiece 102 to rotate, i.e. 
pivot cam 96, and rotate dead bolt swivel 72. Tailpiece 
102 in conventional fashion has a flat elongated con- 
figuration with a generally rectangular cross section, 
there being a corresponding cross section in the open- 
ing of swivel 72, and in opening 96a of cam 96 as well 
as the opening in turnpiece 68. 
Like other technical texts or marketing texts, for instance, 
patent or patent application text can be sampled 902 in 
various ways. For instance, here is a partial copy of the 
excerpt given above, with every third sentence removed 
1002 by samphng; omission locations are marked here for 
clarity of illustration but would not necessarily be marked in 
every sample: 

<omitted> This tailpiece 102 thus extends through the 
matching opening in security dead bolt swivel 72, 
through bearing 100, through elongated vertical slot 98 
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of slide 90, through matching opening 96a in driven 
cam 96, and into a matching opening in turn piece 68, 
all as shown in FIG. 3. Therefore, rotation of the 
cylinder lock and tailpiece 102 by a key 71 will rotate 
dead bolt swivel 72 to extend or retract dead bolt 58, 5 
depending upon the direction of rotation, and will also 
rotate cam 96 and turnpiece 68. <omitted> Tailpiece 
102 in conventional fashion has a flat elongated con- 
figuration with a generally rectangular cross section, 
there being a corresponding cross section in the open- 
ing of swivel 72, and in opening 96a of cam 96 as well 
as the opening in turnpiece 68. 
Alternatively, text could be sampled 902 to create a 
distorted and partial copy using a "dictionary scramble" 
technique. The text is at least partially scanned, and a 
dictionary of words used in the text is created. The selected 15 
words are placed in an order; this could be the order in which 
they were encountered, or alphabetic order. Then replace- 
ments are made in a copy, by substituting a second word in 
the list for a first word in the list each time the first word is 
encountered in the copy. The modified copy will be the 20 
sample. 

In the example below, the dictionary listing used is 
"Bearing, 100, supports". In this example, two passes are 
made through the text, and during each pass each instance of 
a currently selected dictionary word is replaced by the word 25 
two positions further along in the dictionary list. Thus, 
instances of "Bearing" are replaced by "supports", and then 
instances of "100" are replaced by "Bearing": 

Supports bearing supports the tailpiece driver 102 that 
extends from key lock 70. This tailpiece 102 thus 30 
extends through the matching opening in security dead 
bolt swivel 72, through supports bearing, through elon- 
gated vertical slot 98 of slide 90, through matching 
opening 96a in driven cam 96, and into a matching 
opening in turnpiece 68, all as shown in FIG. 3. 35 
Therefore, rotation of the cylinder lock and tailpiece 
102 by a key 71 will rotate dead bolt swivel 72 to 
extend or retract dead bolt 58, depending upon the 
direction of rotation, and will also rotate cam 96 and 
turnpiece 68. Likewise, rotation of turnpiece 68 will 40 
rotate tailpiece 102 to rotate, i.e. pivot cam 96, and 
rotate dead bolt swivel 72. Tailpiece 102 in conven- 
tional fashion has a flat elongated configuration with a 
generally rectangular cross section, there being a cor- 
responding cross section in the opening of swivel 72, 45 
and in opening 96a of cam 96 as well as the opening in 
turnpiece 68. 

Of course, many other sampling techniques can also be 
used according to the present invention. For instance, the 
broker 504 could also scramble 1004 data to create a sample. 50 
Scrambling could mismatch names and addresses in a mail- 
ing list so that each name or address is individually correct 
but the names do not always match the indicated addresses. 
Similarly, scrambling could transpose entries in a table of 
numeric values, or it could change the order of statements in 55 
program source code. Scrambling and/or other distortions 
could be combined with omission, so that a portion of the 
data is first extracted and then distorted to create the sample. 

The broker could also mix 1006 spurious data into a copy 
of the original digital content, such as by adding spurious 60 
addresses to a mailing list, adding spurious values to tables 
of data values, or adding spurious statements to source code. 
The presence of spurious data in maps, and of "bugs" in 
source code, has been used conventionally to show copy- 
right infringement, but the use of such data according to the 65 
present invention to provide a digital sample 508 to facilitate 
commerce is believed to be novel. 
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For instance, spurious source code could be added 1006 
by copying a loop or a function call, altering numeric 
parameters, and then inserting the resulting spurious code 
before or after the original code loop or function call. This 
technique has a good chance of breaking the sample's 
functionality to make it unsuitable for normal use as digital 
goods, as desired, without making the spurious addition easy 
to identify or remove. The modified code will usually still 
compile and link with the same error messages, or lack 
thereof, as it did before sampling 902. 
Catalogs 

Some embodiments provide a catalog containing samples 
according to the invention. This permits prospective buyers 
to inspect samples without making the sampled goods easily 
available for unauthorized use. Like conventional catalogs, 
catalogs according to the invention may contain text and/or 
pictures describing the offered products and services. The 
catalog may also contain samples of software that are 
conventional in the sense that they provide only a limited 
subset of functions (e.g., no print capability) and/or stop 
working after a previously specified number of uses or a 
previously specified period of time has passed. But the novel 
catalogs also have sampled 902 content according to the 
invention. 

Systems and Devices 

FIGS. 11 and 12 illustrate some of the many possible 
configurations of systems and devices suitable for use 
according to the present invention. In FIG. 11, a seller 
computer 1100 and a buyer computer 1102 are each con- 
nected to a server 1104 that runs automatic broker 504 
software. The seller connection 1106 and the buyer connec- 
tion 1108 are not necessarily identical in bandwidth, latency, 
geographic scope, networking protocols, addressing, or 
other characteristics. Either or both connections 1106, 1108 
may include local area network, Internet, or other network 
connections, including wired or wireless connections, inter- 
vening routers, servers, or other computers, telephone lines, 
and/or a combination of these and other familiar or yet-to- 
be-invented technologies for transmitting digital content. 
The illustrated configured storage medium 1110 is described 
in detail elsewhere herein. 

FIG. 12 illustrates one of many possible embodiments of 
the broker 504; for completeness, FIG. 12 illustrates features 
that are not required in every embodiment. 

In the illustrated embodiment, the broker 504 includes 
one or more goods servers 1200 and one or more sample 
servers 1202. Goods and samples are separated in this 
implementation for increased security, but may be combined 
in other embodiments, for faster response, increased ease of 
maintenance, or lower cost, for instance. 

The servers may be implemented using physically sepa- 
rate (but networked) machines, or using logically separate 
server processes running on the same underlying computer 
hardware. In the case of separate machines, network con- 
nections 1204, 1216 permit communication between the 
machines. Suitable network connections include those 
known in the art. 

An optional access control module 1206 controls access 
by the parties to a transaction (and by other entities) to a 
storage 1208 which contains escrowed digital goods. Oper- 
ating system, file system, distributed directory, public key 
infrastructure, firewall, and/or other familiar access controls 
may be used to implement the access control module 1206. 
The storage 1208 may be implemented using disks, RAID 
systems, and/or other computer data storage media and 
devices. 

An optional accounting/logging module 1210 performs 
accounting and/or logging operations. Logging uses familiar 
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activity logging technology to maintain a log of the accesses 
granted or denied by the access control module 1206, the 
source and date on which goods were escrowed into the store 
1208, transfers of digital content samples from the goods 
server 1200 to the sample server 1202, and/or other activity. S 
The logs may be kept for enhanced security, to assist testing 
or debugging of the broker 504 software and/or hardware, or 
for other reasons. For instance, the logs may be used by 
accounting routines in the module 1210 to charge parties for 
escrow services, transactional activity, and/or sampling per- 10 
formed by the broker 504 for those parties. 

An optional cataloging module 1212 creates catalogs, 
using novel samples according to the present invention. The 
catalogs may also contain conventional descriptions and 
samples of digital and/or non -digital goods, or services. 15 
Catalogs may take the form of one or more web pages 
(possibly with associated images and/or sounds), PDF or 
other integrated text-and-image files, multi-media 
presentations, or other formats for presenting digital content 
to prospects for purchase or a barter exchange. 20 

An optional sampling module 1214 creates samples 1222 
of digital content as discussed herein. The source digital 
content may be read from escrowed digital goods in the store 
1208. Samples 1222 may also be created 902 "on-the-fly" by 
reading source content over the network connection(s) 1106, 25 
1108, processing it (e.g., by 1004 distortion), and providing 
the resulting sample 1222 as output without escrowing the 
sampled goods. 

In the illustrated embodiment, an optional sample man- 
ager 1218 stores and retrieves samples 1222 from a sample 30 
store 1220. The sample manager 1218 may also include 
access control, accounting, logging, and/or cataloging rou- 
tines. The storage 1220 may be implemented using RAM, 
disks, RAID systems, and/or other computer data storage 
media and devices. 35 

An optional transaction manager 1224 tracks the state and 
progress of a transaction. In some embodiments, the trans- 
action is a goods-for-payment transaction of the types illus- 
trated in one or more of FIGS. 5-7 and notation examples 
T4Q, T4Q', T5Q, T6Q, T7. In some embodiments, the 40 
transaction is a goods-for-goods barter transaction of the 
type illustrated in FIG. 8. In either case, the transaction 
manager 1224 includes routines and supporting hardware for 
steps such as authenticating parties, receiving and escrowing 
goods, obtaining and providing samples, obtaining and 45 
providing catalogs, receiving approvals and/or noting 
implicit approval by lack of cancellation after a specified 
time, releasing payments and/or goods to complete a 
transaction, and billing parties for services rendered. Which 
steps are present depends on the embodiment in question. 50 

An authentication module 1226 and a network connection 
1228 may also be present, to provide buyers with controlled 
access to samples 1222 from the sample store 1220. These 
modules may be implemented using the same or similar 
tools and techniques as those in the access control 1206 and 55 
other network connection 1204, 1216 components, respec- 
tively. 
Conclusion 

The invention provides methods, systems, and other 
embodiments for facilitating transactions involving digital 60 
content. Tools and techniques are provided for addressing 
various trust issues. Some of these issues are common to a 
wide variety of transactions, while other trust issues arise 
with particular strength in transactions that involve digital 
goods. 65 

To address such issues, in some methods of the invention 
a seller 500 makes a copy of its digital content accessible to 



an automatic broker tool 504, which creates 902 a sample of 
the digital content. The sample's content is not predicted by 
the seller, so a buyer 502 can rely on the accuracy of the 
sample as an indicator of the nature and characteristics of the 
goods. The sample provides useful information about the 
digital content without giving the buyer 502 a complete and 
accurate copy of the digital content, so the seller 500 can 
make information about the goods available to the buyer 502 
without thereby increasing the risk of unauthorized use of 
the goods. 

The sample may be created 902 by distorting at least a 
portion of the digital content, by burdening at least a portion 
of the digital content with spurious data, by extracting a 
portion of the digital content and thereby omitting the 
remaining portion of the digital content, or by some com- 
bination of these steps. Authentication information may be 
placed in the sample as part of a burdening step 1006, 
thereby permitting authentication which verifies that the 
automatic broker tool 504 is the source of the sample. The 
sampling technique may selected by the automatic broker 
tool 504 in response to an identification (by the tool or by a 
user) of the data type of the digital content, e.g., "prose text" 
or "Microsoft Excel Database". The sample may be pro- 
vided to the buyer 502 for inspection, may be provided to the 
seller 500, and/or may be placed in a catalog 904 of the 
seller. 

In addition to providing samples, the automatic broker 
tool 504 may track the state of a transaction, accept goods 
for escrow 506, 800, note approvals 808, 810, release 
payments 510, and/or release goods 514, 812, 814. In 
completing a transaction, for instance, the broker 504 may 
release a copy of the digital content to at least one of the 
buyer 502 and an agent for the buyer, and may release a 
payment from the buyer to at least one of the seller 500 and 
an agent for the seller. 

In some embodiments, an automatic broker tool 504 for 
facilitating transactions involving digital content includes a 
goods store 1208 for storing digital goods escrowed with the 
automatic broker tool, a sampling means (e.g., software/ 
hardware implementing one or more of the steps 1002, 1004, 
1006) in a module 1214 for creating a sample of digital 
goods, and a processor in a computer 1104 operable in 
connection with a configured memory of that computer to 
provide samples created by the sampling means and to 
escrow digital goods in the goods store. In one embodiment, 
the processor is also operable in connection with the con- 
figured memory to complete transactions by releasing 514 
escrowed digital goods to a first party and releasing 512 a 
corresponding payment to a second party. In one 
embodiment, the processor is also operable in connection 
with the configured memory to complete transactions by 
releasing 814 escrowed digital goods of a first party to a 
second party and releasing 812 escrowed digital goods of the 
second party to the first party. 

In some embodiments, an automatic broker tool 504 for 
facilitating barter transactions involving digital content 
includes the escrowed goods store 1208, and the digital 
goods are provided by at least two parties. The computer 
1104 processor is operable in connection with the configured 
memory to escrow digital goods for the parties in the goods 
store 1208, to receive 808, 810 goods release approvals from 
the parties, and in response to those release approvals to 
complete a barter transaction by releasing 812, 814 
escrowed goods to parties other than the parties that pro- 
vided them to be escrowed. The broker may include a 
distorting sampling means for creating a sample by distort- 
ing 1004 a copy of at least a portion of the digital goods, 
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such as by changing the order of data in the digital content. 
The broker may include a burdening sampling means for 
creating a sample by adding data to a copy of at least a 
portion of the digital goods, such as by adding stegano- 
graphic data and/or spurious data to a copy of at least a 
portion of the digital goods. 

A sample 1222 may be provided in the store 1220, from 
sampling module 1214 or as the result of a step 902. The 
sample 1222 of digital content may be produced according 
to the invention by a process for facilitating a transaction 
involving digital content possessed by a party (500, 502, or 
otherwise), the process comprising the steps of the party 
making a copy of the digital content accessible to an 
automatic broker tool 504, and the automatic broker tool 
creating 902 a sample of the digital content. The sample is 
characterized in that its content is not predicted by the party, 
whereby the sample contains useful information about the 
digital content without containing a complete and accurate 
copy of the digital content. 

Some embodiments include a configured computer stor- 
age medium 1110 which will cause at least a portion of a 
computer system 1100, 1102, and/or 1104 to perform 
method steps for facilitating transactions involving digital 
content provided by a party, the method comprising the party 
making a copy of the digital content accessible to an 
automatic broker tool 504, and the automatic broker tool 
creating a sample 1222 of the digital content, the sample's 
content not predicted by the party as discussed above. In one 
method the party escrows the digital content with the 
automatic broker tool. In one method the broker creates the 
sample by distorting at least a portion of the digital content. 
In one method the broker creates the sample by burdening at 
least a portion of the digital content with spurious data. 

Some configured computer storage medium 1110 embodi- 
ments will cause at least a portion of a computer system 
1104 to perform method steps for facilitating barter trans- 
actions involving digital content, by receiving from a first 
party a copy of first digital content and escrowing that first 
digital content; receiving from a second party a copy of 
second digital content and escrowing that second digital 
content; determining an approval exists to release the first 
digital content to the second party; determining an approval 
exists to release the second digital content to the first party; 
releasing the first digital content to the second party; and 
releasing the second digital content to the first party. 

Some configured computer storage medium 1110 embodi- 
ments will cause at least a portion of a computer system 
1100, 1102, 1104 to perform method steps for facilitating 
transactions involving digital content, the digital content 
provided by a seller 500, by receiving from the seller a copy 
of digital content and escrowing that digital content, and 
creating 902 a sample of the digital content, including at 
least one of distorting a copy of at least a portion of the 
digital content and adding spurious data to a copy of at least 
a portion of the digital content. The sample creating step 
may place authentication information in the sample, thereby 
permitting authentication which verifies the source(s) of the 
sample. 

In connection with a method for facilitating barter trans- 
actions using an automatic broker tool 504, one method of 
the invention includes the steps of obtaining a description of 
the automatic broker tool and employing the description by 
advertising at least one of the automatic broker tool and a 
barter transaction service which uses the automated broker 
tool. Similarly, in connection with a method for using 
sampling 902 to facilitate digital content transactions, 
another method of the invention includes the steps of 
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obtaining a description of a configured computer storage 
medium 1110 and employing the description by advertising 
at least one of a configured computer storage medium and a 
service which uses the configured computer storage 
S medium. 

Although particular embodiments of the present invention 
are expressly illustrated and described individually herein, it 
will be appreciated that discussion of one type of embodi- 
ment also extends to other embodiment types. For instance, 
the description of the methods illustrated in FIGS. 5 through 
10 also helps describe the systems and devices in FIGS. 11 
and 12, and vice versa. 

As used herein, terms such as "a" and "the" and desig- 
nations such as "device", "item", and "step" are inclusive of 
one or more of the indicated element. In particular, in the 
15 claims a reference to an element generally means at least one 
such element is required. 

The invention may be embodied in other specific forms 
without departing from its essential characteristics. The 
described embodiments are to be considered in all respects 
20 only as illustrative and not restrictive. Headings are for 
convenience only. The scope of the invention is, therefore, 
indicated by the appended claims rather than by the fore- 
going description. All changes which come within the mean- 
ing and range of equivalency of the claims are to be 
25 embraced within their scope. 

What is claimed and desired to be secured by patent is: 

1. A method for facilitating transactions involving digital 
content, the digital content provided by a seller, the method 
comprising the steps of: 

30 the seller making a copy of the digital content for a 
transaction accessible to an automatic broker tool; and 

the automatic broker tool creating a sample of the digital 
content, the sample characterized in that its content is 
not predicted by the seller, whereby the sample con- 
35 tains useful information about the digital content with- 
out containing a complete and accurate copy of the 
digital content, thereby preventing an unauthorized use 
of the digital content, 

2. The method of claim 1, wherein the broker creates the 
40 sample by distorting at least a portion of the digital content. 

3. The method of claim 1, wherein the broker creates the 
sample by burdening at least a portion of the digital content 
with spurious data. 

4. The method of claim 1, wherein the broker creates the 
45 sample by extracting a portion of the digital content and 

thereby omitting the remaining portion of the digital content. 

5. The method of claim 1, further comprising the step of 
placing the sample in a catalog of the seller. 

6. The method of claim 1, further comprising the step of 
50 the automatic broker tool providing the sample to the seller. 

7. The method of claim 1, further comprising the step of 
the automatic broker tool providing the sample to a buyer for 
inspection. 

8. The method of claim 7, further comprising the step of 
55 the automatic broker tool completing a transaction, the 

completing step comprising releasing a copy of the digital 
content to at least one of the buyer and an agent for the 
buyer. 

9. The method of claim 8, wherein the automatic broker 
60 tool also releases a payment from the buyer to at least one 

of the seller and an agent for the seller while completing the 
transaction, 

10. The method of claim 8, wherein the automatic broker 
tool also releases digital content from the buyer to the seller 

65 while completing the transaction. 

U. The method of claim 1, wherein the step of creating a 
sample comprises placing authentication information in the 
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sample, thereby permitting authentication which verifies that 
the automatic broker tool is the source of the sample. 

12. The method of claim 1, wherein the automatic broker 
tool creates a sample using at least one technique which is 
selected by the automatic broker tool in response to identi- 5 
fying a data type of the digital content. 

13. An automatic broker tool for facilitating transactions 
involving digital content, the tool comprising: 

a goods store for storing digital goods escrowed with the 
automatic broker tool; io 

a sampling means for creating a sample of digital goods; 
and 

a processor operable in connection with a configured 
memory to provide samples created by the sampling 
means and to escrow digital goods in the goods store. 

14. The automatic broker tool of claim 13, wherein the 
processor is also operable in connection with the configured 
memory to complete transactions by releasing escrowed 
digital goods to a first party and releasing a corresponding 
payment to a second party. 

15. The automatic broker tool of claim 13, wherein the 
processor is also operable in connection with the configured 
memory to complete transactions by releasing escrowed 
digital goods of a first party to a second party and releasing 
escrowed digital goods of the second party to the first party. 

16. An automatic broker tool for facilitating barter trans- 
actions involving digital content, the tool comprising: 

a goods store for storing digital goods to be escrowed, the 
digital goods provided to the automatic broker tool by 3Q 
at least two parties; and 

a processor operable in connection with a configured 
memory to automatically escrow digital goods for the 
parties in the goods store, to receive goods release 
approvals from the parties, and in response to those 35 
release approvals to automatically complete a barter 
transaction by releasing escrowed goods to parties 
other than the parties that provided them to be 
escrowed. 

17. The automatic broker tool of claim 16, further com- 40 
prising a distorting sampling means for creating a sample by 
distorting a copy of at least a portion of the digital goods. 

18. The automatic broker tool of claim 17, wherein the 
distorting sampling means changes the order of data in the 
digital content. 45 

19. The automatic broker tool of claim 16, further com- 
prising a burdening sampling means for creating a sample by 
adding data to a copy of at least a portion of the digital 
goods, 

20. The automatic broker tool of claim 19, wherein the 50 
burdening sampling means adds steganographic data to a 
copy of at least a portion of the digital goods. 

21. The automatic broker tool of claim 19, wherein the 
burdening sampling means adds spurious data to a copy of 

at least a portion of the digital goods. 55 

22. A sample of digital content produced by a process for 
facilitating a transaction involving digital content possessed 
by a party, the process comprising the steps of: 

the party making a copy of the digital content for a 
transaction accessible to an automatic broker tool; and go 

the automatic broker tool creating a sample of the digital 
content, the sample characterized in that its content is 
not predicted by the party, whereby the sample contains 
useful information about the digital content without 
containing a complete and accurate copy of the digital 65 
content, thereby preventing an unauthorized use of the 
digital content. 



23. A configured computer storage medium which will 
cause at least a portion of a computer system to perform 
method steps for facilitating transactions involving digital 
content, the digital content provided by a party, the method 
comprising the steps of: 

the party making a copy of the digital content for a 
transaction accessible to an automatic broker tool; and 

the automatic broker tool creating a sample of the digital 
content, the sample characterized in that its content is 
not predicted by the party, whereby the sample contains 
useful information about the digital content without 
containing a complete and accurate copy of the digital 
content, thereby preventing an unauthorized use of the 
digital content. 

24. The configured computer storage medium of claim 23, 
wherein the method further comprises the step of the party 
escrowing the digital content with the automatic broker tool. 

25. The configured computer storage medium of claim 23, 
wherein the broker creates the sample by distorting at least 
a portion of the digital content. 

26. The configured computer storage medium of claim 23, 
wherein the broker creates the sample by burdening at least 
a portion of the digital content with spurious data. 

27. A configured computer storage medium which will 
cause at least a portion of a computer system to perform 
method steps for facilitating barter transactions involving 
digital content, the digital content provided by at least two 
parties, the method comprising the computer-implemented 
steps of: 

receiving from a first party a copy of first digital content 

and escrowing that first digital content; 
receiving from a second party a copy of second digital 

content and escrowing that second digital content; 
determining an approval exists to release the first digital 

content to the second party; 
determining an approval exists to release the second 

digital content to the first party; 
releasing the first digital content to the second party; and 
releasing the second digital content to the first party. 

28. The configured computer storage medium of claim 27, 
wherein at least one of the determining steps comprises 
receiving an approval from the party mat provided the 
digital content being approved for release. 

29. The configured computer storage medium of claim 27, 
wherein at least one of the determining steps comprises 
timing out after no cancellation is received from the party 
that provided the digital content being approved for release. 

30. The configured computer storage medium of claim 27, 
wherein the method further comprises the steps of creating 
a sample of digital content; and sending the sample to at 
least one of the parties prior to at least one of the determining 
steps. 

31. The configured computer storage medium of claim 27, 
wherein the digital content includes an image and the step of 
creating a sample creates a thumbnail of the image. 

32. A configured computer storage medium which will 
cause at least a portion of a computer system to perform 
method steps for facilitating transactions involving digital 
content, the digital content provided by a seller, the method 
comprising the steps of: 

receiving from the seller a copy of digital content and 
escrowing that digital content; and 

creating a sample of the digital content, including at least 
one of distorting a copy of at least a portion of the 
digital content and adding spurious data to a copy of at 
least a portion of the digital content. 
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33. The configured computer storage medium of claim 32, 
wherein the sample creating step further comprises placing 
authentication information in the sample, thereby permitting 
authentication which verifies the source of the sample. 

34. A method for facilitating barter transactions involving 5 
digital content using an automatic broker tool for facilitating 
barter transactions involving digital content, the tool com- 
prising a goods store for storing digital goods to be 
escrowed, the digital goods provided to the automatic broker 
tool by at least two parties, the tool further comprising a 10 
processor operable in connection with a configured memory 

to escrow digital goods for the parties in the goods store, to 
receive goods release approvals from the parties, and in 
response to those release approvals to release escrowed 
goods to parties other than the parties that provided them to 15 
be escrowed, the method comprising the steps of obtaining 
a description of the automatic broker tool and employing the 
description by advertising at least one of the automatic 
broker tool and a barter transaction service which uses the 
automated broker tool. 
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35. A method for facilitating transactions involving digital 
content, the method comprising the steps of obtaining a 
description of a configured computer storage medium and 
employing the description by advertising at least one of a 
configured computer storage medium and a service which 
uses the configured computer storage medium, the computer 
storage medium configured to cause at least a portion of a 
computer system to perform steps in a process, the digital 
content provided by a party, the process comprising the party 
making a copy of the digital content for a transaction 
accessible to an automatic broker tool, the process further 
comprising the automatic broker tool creating a sample of 
the digital content, the sample characterized in that its 
content is not predicted by the party, whereby the sample 
contains useful information about the digital content without 
containing a complete and accurate copy of the digital 
content, thereby preventing an unauthorized use of the 
digital content. 

* * * * * 
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[57J ABSTRACT 

A network based hypertext display system employing a 
supervisory computer interconnected with one or more 
information display units and one or more remote document 
servers via a network, such as the Internet. The supervisory 
computer controls the content displayed by the display units 
by transferring to each unit a control information file as well 
as hypertext document files which are locally stored in the 
display units. The control file determines the extent to which 
the display unit can access remotely stored information and 
provides additional information which is used to alter the 
presentation to the user. Stored control information is used 
to rewrite hypertext document such that certain links are 
disabled, and to suppress the appearance of visual cues 
associated with the displayed anchor which identifies 
selected links in the referencing document. Links and other 
information in local and remotely accessed documents are 
rewritten in accordance with commands created by a content 
developer using an interactive content authoring system 
Means are employed for controlling the duration of a given 
user session in response to the material selected for display, 
the time of day, and user demographics. Locally stored data 
copied from original documents stored on remote servers is 
periodically validated and updated when the validation 
indicates that the original has been modified. 

18 Claims, 12 Drawing Sheets 
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SUPERVISED SATELLITE KIOSK unit identifies those documents which are Locally stored 

MANAGEMENT SYSTEM WITH COMBINED copies of original documents stored in remote servers, 

LOCAL AND REMOTE DATA STORAGE together with the record location identifier for those original 

documents. The display unit processor further comprises 
FIELD OF THE INVENTION 5 request processing means for redirecting display requests 

™. . 1* * 1 , • . f , ; , fthu which identify such remotely stored document such mat the 

BACKGROUND OF THE INVENTION 10 by comparing attributes of those stored copies against data 

... , . describine the originals retrieved from the supervisory com- 

Kiosks equipped with touchscreens have proven to be a ^ and ^ onns a aall sfet of modified 

highly effective means for conveying useful information to ^ mc rcmotc locatioll into local storage 

the public. In retail stores, for example, kiosks can provide whenever Ae validation comparison indicates a need to 

directory information to help customers find needed prod- ^ g ^ ^ The validation means preferably 

ucts while promoting featured items. Placed in corporate c ^ ses means for cyclically scanning the entries in the 

lobbies, showrooms or trade show booths, the kiosk can be j^n^n me to idcntif y locally stored files and 

an effective sales tool, allowing the user to select text and locations rf their remote counterparts, together with 

graphical information of particular interest In malls, airport indicati fte ^ wnen the locally stored file was 

lobbies, community information centers, and other public ^ ^ ^ whcn fce locally stored me was i as , 

areas, the kiosk can effectively answer questions, guide y)Ji daied. ^ means responsive to idle conditions at me 

visitors to desired locations, and publicize the products and terminal for performing validation testing and 

services offered by the kiosk's sponsors. update transfers when the display terminal is not in use. 

Because kiosks can be readily implemented with tara- ^ ^ ^ by ^ invC nti 0 n. each display 

pensive personal computers and touchscreen monitors, the M mcaQS for fwini a record of the information 

principal cost of a typical bosk-based informabon system is cste<1 by users at each display unit and for transferring 

incurred in designing and implementing the software which ^ rccofd ^ me ^ lay unit t0 me supervisory proces- 

generates the desired interactive displays. This «P=nse ^ ^ ^ recfflrd prefe^y identifies a particular 

typicaUy grows as the displays are continually altered to doauaejA d^yed. the time when that particular document 

reflect new information. M was ^ me idenUty of the user. 

Interactive displays which are closely similar is style and ^ ^ ^ ^ invention me information 

content to those needed for kiosk systems are now being t<> whkh each „ . unit ^ tted ^ defined by the 

created in large quantities by businesses seeking the expo- ^ mation of ^ locaUy stored data and access control 

sure offered by me World W!de Web the Internet system of informatio|1 which is aaD dcncd to the display unit from an 
interlinked hypertext documents. Businesses. insutuUons J3 m ^ tetiM t0 ^o, ^ conteD , made available at the 

and individuals are presenting a rapidly increasing volume ^g^y unit. 

of promotional, tutorial, entertainment, and reference infor- ~L . . ... ^ <• . „ »t t u- :_.,...»:^„ ..,;n 

'7 . ... . jmj ... These and other objects and features of the invention will 

mation on mteracuve "web i^g« made ^ » become mire apparent through a consideration of the fol- 

any computer having standard web browsing software and w» ^ of * felred embodiment of me 
an Internet service connection. w .^J^ ^ ^ ^ rf ^^on, frequent refer- 

SUMMAKY OF THE INVENTION ence will be made to the attached drawings, 

It is an object of the present invention to facilitate the BRIEF DESCRIPTION OF THE DRAWINGS 

programming, monitoring and control of one or more Infor- fkj. 1 is a illustration of the principal components used 

mation display units which are remotely located from a 45 . lanent a programmable, interactive HTML display 

supervisory computer which provides the content for and J* ; embodying the invention; 

monitors me operation of the display units over telecom- > ^ Qf ^ component, 0 f 

munication pathways „.,„.,• * controlled access HTML display system employed to 

In accordance with the invention, each inf ormauon dis- - , ement an cmbo diment of the kiosk unit employing the 

play unit is provided with its own processor and display 50 jnXntion- 

screen which preferably takes the form of a touch screen • illustrating the operation of the 

capable of accepting selections from a user. " ™U astocaJ ^ J ^ ^ * ^ *~ 

storage means for persistently storing programs, hypertext ll " " J KJ mn „ ^ a A i^ na 

documents to be displayed, and control iiiformation. Each HO- f the on-screen >H»<^ 2 

such display unit is Liner provided with communications 55 wed to ^teracUvely obtain ^^ 0 ^7^ D S the 

facilities which provide a file transfer pathway to a remote operation of hypertext unto found in HTML pages 

supervisory computer which, along with other server com- FIG. 5 shows the on-screen appearance of a dialog box 

outers made available by the communications facilities, may used to obtain information defining the manna in which text 

remotely store displayable infonnation in the form of hyper- information found in an HTML document is automatically 

text documents, executable applets, imbedded image data, 60 rewritten to implement the invention; 

and related files. Control processing means executing on FIG- 6 Illustrates the on-screen appearance of a dialog box 

display unit processor responds to user selections to access employed to interactively obtain control information which 

displayable documents stored on both the local storage defines or redefines links appearing in displayed hypertext 

means and provided via the communications facility from documents; 

one or more identified remote servers. 65 FIG. 7 is a flow chart which illustrates the manner in 

As contemplated by the invention, a control information which information supplied by the dialog box of FIG. 4 is 

file transferred from a supervisory computer to each display utilized by the invention; and 
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FIG. 8 is a flow chart which depicts a routine for utilizing 
informatioo supplied by means of the dialog boxes of FIGS. 
5 and 6; 

FIG. 9 is a flow chart illustrating a mechanism for 
automating a content development session during which Che 
information which may be accessed by a kiosk user is 
defined; 

FIG. 10 shows the on-screen appearance of a dialog box 
used to accept information defining the manner in which the 



data stored at the kiosk 10. Alternatively, file transfers 
between the authoring computer 30 and the kiosk computer 
11 may be accomplished over the SLEPP/PPP Internet con- 
nection using HTTP or FTP file transfers. 

As discussed later, computer 11 In kiosk 10 stores hyper- 
text browsing and control programs as indicated at 60, one 
or more files of access control data as indicated at 70, and 
locally stored hypertext documents indicated generally at 80 
which are displayed on the touchscreen 12 in the kiosk 10. 



- w -"-^ f» uummuuwu wvumug U1V UIOUUU 114 WIUHI U1& * r — — - — w ■ 

duration of an individual user session is limited based upon 10 ^ P ro SF™M <»0, control data files 70, and the displayable 



the character of the documents selected for viewing, the time 
of day, and information characterizing the particular user; 

FIG. 11 is a flow chart describing a routine for limiting the 
duration of a given user session in response to a particular 
document being viewed and other information provided by 
the dialog box of FIG. 10 and for recording usage data; 

FIG. 12 is a flow chart illustrating the manner in which the 
display unit exchanges information with an authoring com- 
puter which provides its original content, and with a super- 
visory computer which receives information describing the 
operation of the display unit; and 

FIG. 13 is a flow chart which describes the manner in 
which the lookup table which relates local storage URL's to 
the original remote URL of the stored document is used to 
translate URL requests and to update the stored files peri- 
odically to match the originating files. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

System Overview 

As seen in FIG. 1, an interactive computer display kiosk 
10 which implements the invention consists of a kiosk 
cabinet within which a personal computer 11 and a touch- 



hypertext data 80 may be periodically updated from time to 
time by transferring information from the authoring com- 
puter 30 to the kiosk computer 11. 
The kiosk programs 60 include conventional web page 
is browsing software such as: the NCSA Mosaic browser 
available from the National Center for Supercomputing 
Applications (Software Development Group), Champaign. 
HI.; Spyglass Mosaic offered by Spyglass, Inc. Naperviile, 
HI.; Netscape Navigator marketed by Netscape Communi- 
20 cations Corp.. Mountain View, Calif.; and Internet Explorer 
offered by Microsoft Corporation, Redmond, Wash. In 
general, these web browsers retrieve and display hypertext 
documents (web pages) written in standard Hypertext 
Markup Language (HTML). 
25 HTML documents take the form of conventional ASCII 
text files which include imbedded tags which format the text 
for display presentation and provide links to graphics files 
containing images which may be imbedded in the 
documents, as well as links to other web pages to which 
30 hypertext jumps may be made. Linked files and documents 
are identified within the imbedded tags in a predetermined 
Uniform Record Locator (URL) format which includes the 
identification of the communications protocol 



used 

(including conventional and secure hypertext protocols 
screen monitor 12 are mounted. The personal computer 11 is 35 respectively. File Transfer Protocol or FTP etc.). the iden- 
connected via a modem 14 and dial-up or leased telephone tification of a particular server computer which stores the 
lines 15 to a remotely located computer 20 which provides referenced file, and the directory and file name of the file 
a conventional serial data SUPP or PPP modem link to the itself on the designated server. Hypertext documents and 
toternet service. The remote computer 20 also operates as a linked files which are stored locally in mass storage and 
World Wide Web server and is connected via high speed 40 directly accessible by the running browser program may also 
Internet TCP/TP Internet network lines 35 to other computers be designated by a URL and interactively displayed in the 
on the Internet, such as the second web server computer seen same way that the browser displays web pages available 
at 25. The servers 20 and 25 provide access to stored from remote servers through the Internet. Extensive Infor- 
information to connected client computers such as the kiosk mation describing HTML, the World Wide Web, and the 
10 and a personal computer 30 which is also connected via 45 Hypertext Transport Protocol/Internet Protocol is available 
a modem SUPPfFFP connection over the telephone lines 15 
to computer 20. The modem 14 provides data communica- 
tions via the telephone SLOTVPPP lines 15 while a modem 
45 similarly provides data communications for the personal 
computer 30. 

The personal computer 11 includes its own local magnetic 
disk drive for persistent mass storage. The computer 30 may 
be used as an authoring site at which the content accessible 
by the kiosk computer 11 is defined and from which dis- 
playable data and control information may be transferred to 55 
the kiosk computer 11. A conventional modem-to-modem 
connection may be established between the modem 14 
attached to kiosk computer 11 and the modem 45 attached to 



in the published literature. See. for example. World Wide 
Web Bible by Bryan Pfaffenberger, MIS:Press, ISBN 
1-55828-410-9 (1995); Netscape and HTML Explorer by 
Urban A. LeJcune, Coriolis Group, ISBN 1-883577-57-1 
50 ( 1995); and Programming WinSock by Arthur Dumas, Sams, 
ISBN 0-672-30594-1 (1994) which describes the WinSock 
Library, one of several Windows Open Services Architecture 
(WOSA) standards being used to add TCP/IP connectivity to 
applications. 

As seen in the illustration of FIG. 1. the hypertext 
documents stored locally on the hard disk of the kiosk 
computer 11 preferably includes an attract page 81 which, as 
illustrated, might contains imbedded hypertext links UNK1 
AND UNK2 to other locally stored pages 82 and 83 



the remote personal computer 30 such that direct file trans- 

fers can be made between the computer 30 and the kiosk 10 60 respectively, as well as LINK3 to a home page 90 stored by 

using a conventional dial-up modem connection via the the web server computer 20, and LINK4 to a further web 

telephone lines 15. To permit such transfers, the kiosk page 95 stored on the web server computer 25. By touching 

personal computer 11 may be programmed to place the the touchscreen 83 at the position where highlighted text, or 

modem 14 in auto-answer mode when the kiosk 10 is not a graphic, which visually represents the linked subject 

being used as a web client, enabling the computer 30 to use 65 matter appears, the kiosk user can request the display of the 

its modem 45 to directly dial the modem 45 to establish a file linked information, which itself typically contains links to 

transfer connection for storing or modifying programs and other web pages, and so on. 
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Using the principles of the invention, the kiosk proprietor 
may limit the kiosk user's access to authorized pages only. 
These constraints are provided by access control programs 
included in the set of programs 60 stored on the hard drive 
of the kiosk computer 11 which are responsive to informs- 5 
tion stored in the control data Mies 70 also stored in computer 
11. The access control programs analyze and rewrite the text 
found in accessed HTML pages before those pages are 
displayed and perform predetermined functions defined by 
stored access control information when the user activates 10 
selected links. 

The access control information itself may be conveniently 
created using the remote authoring computer 30 by browsing 
a combination of locally stored hypertext documents and 
remote web pages while responding appropriately to 15 
requests for access control information which is generated 
during an interactive development session. After the control 
information and the locally stored hypertext documents are 
created at the authoring computer 30, both may be uploaded 
to one or more kiosk computers, such as kiosk computer 11, 20 
using a conventional modem dial up file transfer or transfers 
over the Internet as noted above. 

The local storage of displayable information supplements 
and should be distinguished from the caching operations 
performed by conventional web browsing and proxy server 25 
software. Such caching systems typically store copies of 
information accessed over the Internet in local disk storage 
until a cache size limit is reached, and then continue to save 
additional data by overwriting the least recently accessed 
data. Because a given item of data may be altered at anytime 30 
at its origin, these caching schemes typically retrieve data 
from the cache only after the originating server verifies that 
the desired data has not been modified since it was originally 
placed in the local cache. For example, the Netscape Proxy 
Server marketed by Netscape Communications Corp.. 35 
Mountain View, Calif, combines the ability to cache data 
accessed from the network using "if modified since" check- 
ing with a high-level access control to prohibit access to 
documents having a specified URL for all or specified hosts. 

In accordance with the present invention, such a caching 40 
mechanism is not required and not burdened with informa- 
tion which the authoring computer 30 designates for storage 
as the original copy, and no access to an originating server 
is required. The performance of the display unit, such as the 
kiosk computer 11. is accordingly enhanced by storing a 45 
significant portion of the content locally and only requiring 
a slower network access to be performed for displayed 
information of the following kinds: 

(1) information which changes so frequently that the 
transmission of updates under the control of the authoring 50 
computer would be inefficient, for example: weather data 
from a news source which includes weather map data which 

is updated every few minutes; 

(2) information which occupies a significant amount of 
space and/or contains items which are individually accessed 55 
only infrequently, for example: individual topics in an online 
encyclopedia which, because of imbedded graphics and the 
like, would be time-consuming to transfer and which would 
consume a large amount of local storage capacity. 

To the extent that information is accessed by the display 60 
unit from the network, it may be cached in the usual way to 
eliminate the need to access information which has not been 
altered by the originating server since the last cache storage 
was performed. 

In the description to follow, attention will first be directed 65 
to the operation of the access control mechanism, including 
the browser, the access control programs, and the stored 



access control data, as the kiosk user interactively operates 
the browser. Attention will then be directed to the mecha- 
nism for interactively creating those access control data 
structures which limit and control the user's access to 
information. 

Access Control Mechanism 

The operation of the user access control mechanism is 
illustrated generally in FIG. 2 of the drawings. Actions are 
initiated when the kiosk user touches a displayed link anchor 
on the kiosk touchscreen as depicted at 103 in FIG. 2. The 
resulting touchscreen signal 105 is processed by the execut- 
ing web browser program 107 which responds by issuing a 
request 109 for the retrieval of displayable data identified by 
a particular URL. 

The request 109 is processed by an access control mecha- 
nism indicated generally at 110 which includes a mechanism 
113 for comparing the URL in request 109 with URLs in 
transition list 111. If the requested URL specified in request 
109 is found in the list 111. a transition display page is sent 
to the web browser 107 while the originally requested URL 
is concurrently sent to the access mechanism 12. This 
transition display mechanism 113, described in more detail 
later in connection with FIG. 13. provides a mechanism for 
displaying one or more display pages to the user before the 
information identified by the requested URL is displayed. 

The access mechanism 120. like the web browser pro- 
gram 107. is conventional URL's which translate into local 
disk addresses, such as: 

"filerC ^WI>^WS\De^top\HTI^\HOMEirrKr 

are accessed directly from local storage, whereas URL's 
which identify information stored on remote servers, such 
as: 



bttp^/wwwjiucolouch^om/produc te/ij234.biml/ t * 

are retrieved by the kiosk computer utilizing TCP/TP 
software, such as the dynamic link library WTNSOOCDLL 
for Windows 3.1 or WSOCK32.DLL supplied by Microsoft 
with Windows 95. Depending on the content of the URL in 
the request 114. the linked data specified by the URL 
Request 114 is obtained either from the kiosk's local storage 
system, illustrated by local disk 122 in FIG. 2, or by 
transmitting an http/ip Internet message requesting the infor- 
mation via a modem 124 and SLIP/PPP connection 126 to 
the remote Internet web server (not shown) which holds the 
requested information. If the access request is successfully 
satisfied, the access mechanism 120 returns the requested 
data in the form of an HTML document, graphical image, 
FTP file, or other displayable data identified by the URL in 
the request 114; otherwise, the access mechanism returns an 
appropriate error message which is displayed to indicate to 
the kiosk user mat the access did not succeed. 
Rewriting Incoming HTML Pages 

When the returned displayable data is an HTML 
document the text of that document is processed by the 
access control mechanism 110 which includes a mechanism 
130 for rewriting the HTML page in accordance with 
information in a string list data structure 133. The string list 
133 typically contains a collection of text replacement 
request commands each including of a designated target 
string and a designated replacement string. Whenever one of 
the target strings in the structure 133 is found within the text 
of an incoming HTML document, that target string is 
replaced by the associated replacement string before the 
incoming HTML document is displayed by the web browser 
program 107. 
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The TargeLJ^ge. Taiget and Replacement fields each hold 
pointers to null-terminated strings (character arrays). The 
Location field is 32-bit integer which holds the position at 
which the replacement string is to be inserted (when Target 
is a null pointer). The Flag field holds boolean flag bits 
having the following significance when true: 



Seaich__Nonnai: 

Seairtu-Anchor: 
Seaich_URL: 

Case_Settsitive: 
Disable_Pasewide: 



Search for Target string in normal (odd- anchor) 
displayabk text; 

Search for Target string in displayable anchor text; 
Search for Target string in URL definition 
within anchor tags; 

Apply case sensitivity to search for Target; 
Disable all links on Target— Poge; 



The versatility of the text replacement mechanism 130 is 
illustrated by the following example replacement com- 
mands. For each example, assume that an incoming hyper- 
text document received at the HTML rewrite mechanism 
130 from the access mechanism 120 includes an imbedded 
"anchor tag" reading: 



<A HREP^http^wjnaiiuxffiynetsp^ of 
Coptepta<\A> 

Such a tag would be displayed by the browser as the 
highlighted anchor text "Table of Contents" which, when 
touched by the kiosk user, would result in a generated 
request to retrieve and display the HTML document file 
designated by the Uniform Record Locator (URL): 



''bxtpyfwwwm^camflnterTitVtxxJblral*. 

This URL identifies a file named 'tochtmT in the "net spot' 
directory of the web server computer named l *mentum r 
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The HIML text replacement function performed at 130 in 
the access control mechanism 110 may be used to provide a 
number or useful functions. In addition to rewriting display- 
able text the rewriting mechanism 130 may add new links 
to additional information which the kiosk owner may wish 
to communicate to the kiosk user, may delete links to 
information which should be hidden to the user, or may 
substitute replacement links. Unlike the URL transition 
display generating mechanism 113, which is capable of 
inserting one or more display pages before a page designated 
by the URL request 109. the mechanism 130 may be used to 
substitute a different target page for the page specified by a 
link imbedded in an incoming HTML document, and may 
also be used to eliminate the highlighting of. or rewrite, the 
displayed anchor text which is associated with the linked 
URL in the HTML page. The string list 133 includes a 
collection of targct+replacement string pairs. The mecha- 
nism 130 searches the HTML page fetched by the access 
mechanism 120. searching for a match to each of the target 
strings, and when found substitutes the replacement string 
for the target string. 

More specifically, each command stored in the string list 
133 takes the form expressed by the following Pascal record 
definition: 



Rep be cment__Command = record 

Target_Page, Target, Replacement: pchar; 
Location: Longinl; 
Flag: word 

End; 



which is available over the Internet using the hypertext 
transport protocol as indicated by the prefix "http". 

EXAMPLE 1 

5 If the string list 133 contains the following Target and 
Replacement fields: 

Target: "http^/wwwjiiam.com/netspot/toc.htnil M 
Replacement: l *fHe:c://newdir/newtoc.htnT 

io where the replacement string is a new URL specifying a file 
named <4 toc.htm n on the kiosk computer's disk storage 
directory "newdir*\ the effect would be to change the anchor 
tag in the HTML text such that the anchor text 'Table of 
Contents** is unchanged and continues to be highlighted but. 

15 when touched, the locally stored file newtochtm would be 
retrieved by the access unit 120 and displayed instead of the 
file on the remote server originally specified. 
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EXAMPLE 2 

Target: <A HREF="http.//www.main.com/netspot/ 
toc.htmT>Table of Contents<\A> 

Replacement: Table of Contents** 
This replacement command removes the associated link and 
25 the highlighting from the displayed text 'Table of Contents". 

EXAMPLE 3 
Target: "Patent Office** 

Replacement: M <A HREF= u http://www.uspto.gov/ 
">Pateot Office<\A>** 

This command rewrites each occurrence of the string 
"Patent Office" such that web browser 107 highlights the 
string as being an anchor text and provides a link to a 
publicly available home page maintained by the U.S, Patent 
Office whenever the anchor text is touched by the kiosk user. 



30 



35 



40 



EXAMPLE 4 

Target_Page: htrpVAvww.ajaxxorn/saleJitmV 
Target "<Head> 

Replacement: "<HeadxMETA HTTP-EQUIV= 
REFRESH CONTENT=*M2; URL= 

rile: c:\newdiiVesale. htnT> 

litis example, unlike the first three, limits the operation of 
45 the command to a designated target page and causes a 
<META . . . > element to be inserted in the document header. 
A Meta element is a standard HTML 3.0 element for 
simulating HTTP response headers in HTML documents 
which, in the example above, operates as a "client pull** 
dynamic HTML document loader. As a consequence, the 
inserted Meta tag causes the target page to be displayed for 
12 seconds, at which time the browser automatically issues 
a URL request to replace the displayed target page with a 
page on the local hard drive specified by me content field of 
the inserted Meta tag. 

EXAMPLE 5 



50 



55 



60 



65 



Target_J»age: htto://www.ajax.con^sale.html/ 
Location: 1243 

Replacement: "<IMG SRC="logo.jpg** ALIGN= 
BOTTOMS 

This command places the replacement string at character 
position 1243 in the HTML document designated by the 
URL given in the target page field of the command. The 
effect in this case is the insertion into the page of a graphical 
JPEG image designated by the relative source file designa- 
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tion "logo.jpg" in the replacement string. Note that the target Alternatively, a server-push mechanism may be used to 

location value identifies a position in the original incoming insert a sequence of one or more leading pages prior to the 

HTML page, before replacement commands have been trailing page identified in the original link request Using the 

employed to rewrite the text. server push mechanism, the browser 107 seen Lnn02is 

5 supplied with the page sequence using the HTTP MIME 

EXAMPLE 6 protocol and the duration of each page is cxtermined by the 

....... u . HTML rewrite mechanism 130 which maintains an open 

Target_J>age: http://www.quigley.hoUinks.html/ connection to the browser 107. enabling replacement pages 

Flags: DisaMe_?agewide=true; t0 ^ sequcn tially placed on the display screen under control 

This command is created when ail links from Target_J>age w of ^ mechanism ^q. Current versions of the Netscape 

are to be automatically disabled by replacing all link tags Nav i gator an( | internet Explorer web browsing programs 

with replacement text which consists of the anchor infor- support dynamic document loading using both linked client 

mation only. p U jj <\tETA> meta elements or a server pushed sequence of 

Adding Insertion Pages HTTP MIME-partitioned pages. 

The transition control list 111 seen in FIG. 2 also consists i5 ^ nonnal operation, the HTML rewrite unit 130 need 

of a series of structured records each of which takes the form only OQ mose HTML documents which are accessed 

expressed by the following Pascal record definition: frora me network, since locally stored HTML documents 

may be stored in rewritten form. In one instance, however, 

T^iti^command = record ' locally stored HTML documents should also be modified 

Trailing, Leading: pchar. 20 dynamically. This occurs when an attempt to access a given 

Showtime: integer; document from a remote server fails because the document 

En* __ described in link contained in a locally stored document is 

~~~ "— — ^— — — - ^— — — ^ longer available from the remote server. In that case, to 

The Trailing and Leading fields contain pointers to null- avoid encouraging the user to attempt to access a remote 

terminated strings which contain the URL's of the trailing 25 document that is no longer available, the outdated link tag in 

and leading pages of page transition, respectively. The the locally stored document should be rewritten to display 

transition display mechanism 113 seen in FIG. 2 searches the the anchor information only and eliminate the link as 

transition control list to determine if the received URL illustrated by the string list command of Example 2 

request 109 contains a URL which matches a trailing URL described earlier. This automatic suppression of the display 

on the list 111. If so, the page identified by the URL in the 30 of visual cues in connection with links that are no longer 

Leading field of the transition command is displayed first. operative is particularly advantageous when the display unit 

and the duration of this display is specified the value is used by inexperienced users who may be confused by 

contained in the Showtime field. error messages returned by the remote server when 

The operation of the transition display mechanism 113 is requested documents are no longer available, 

illustrated in more detail by the flowchart presented in FIG. 35 Interactive Access Control Development 

3. The transition control routine is executed by the kiosk As noted earlier, the creation of the software content of an 

computer during an interactive user session each time the effective interactive kiosk display system is typically quite 

user touches the kiosk touchscreen to cause the browsing costly. The ability to utilize existing web pages and HTML 

program to generate a hypertext link request seen in FIG. 2 browsing software can significantly reduce these costs, so 

as URL request 109. When the transition display mechanism 40 long as suitable safeguards are incorporated to prevent the 

113 receives that request the routine shown in FIG. 3 is user from accessing undesired web pages and to affirma- 

executed beginning at the entry point 151. tively guide the user's attention to desired information. The 

At 152, the transition list seen at 111 in FIG. 2 is searched. creation of such an access control mechanism may also be 
If the URL in the received URL request is found in the made an interactive process which may be performed by 
Trailing field of a transition command record, that record is 45 kiosk proprietors with little or no training in either program- 
tested at 152 to determine whether the Leading field contains ming or HTML page creation. 

a null pointer. From the kiosk owner's perspective, the development 

If no leading URL is specified, the routine selects a process merely requires that the HTML pages being made 

display page from a collection of available pages as seen at available to the user be browsed to activate links to other 

154. This selection may be made randomly from a collection 50 pages, supplying link control information when requested by 

of pages placed in a predetermined directory on the kiosk the development program, and adding or editing links and 

computer's local hard drive (seen at 122 in FIG. 2), or by text to the pages which are presented. An introductory 

cycling through a list of insertable display page URLs. If the explanation of the interactive development process is best 

Leading field of the transition command contains a specific illustrated by FIGS. 4-6 of the drawings, each of which 

URL mat URL is roduded at 156 to me outgom^ 55 illustrates the content of a dialog box presented to the 

request seen at 114 in FIG. 2. developer during the course of a development session. 

Whether quasi-randomly selected at 154 or specifically During the development session, the developer operates 

identified as indicated at 156, the value indicating that the development software, to be discussed later, which operates 

requested URL identifies an insertion page, and a pointer to as a conventional web browser FIG. 4 shows a Link 

the satisfied transmon conunand in list 111. are passed to the 60 Handling dialog box which is displayed each time the 

HTML rewrite routine 130 as indicated at 160 in FIG. 2. The developer activates a link imbedded in the currently dis- 

inscrtion page retrieved by the access mechanism 120 is then played document to produce a URL request. The Link 

rewritten (as illustrated by Example 4 above to place a client Handling dialog box contains a •Target" area for the entry 

pull <META> element in the header of the leading page of information specifying the handling of the linking 

which identifies the trailing page URL and the desired 65 function, and a 'Transition Display" area for the entry of 

display duration (Showtime) in the inserted <META> ele- information specifying the manner in which insertion pages 

mcDt are to be displayed prior to the requested information. 
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In the "Target" area of the Link Handling dialog box seen 
in FIG. 4, the fully qualified URL of the HTML page to be 
displayed next is shown at 201 at the left of a preview button 
203. By pressing the button 203, the developer may view 
(but not link from) the document identified by the URL 
displayed at 201. The developer may select among the 
options OK. Prevent and Substitute made available by the 
radio buttons 205. 
If "Prevent" is selected using radio buttons 205. the 



12 



those which were locally stored at the request of the 
developer, may be rewritten in accordance with the stored 
string replacement commands on list 133 at the conclusion 
of the development session, eliminating the need for per- 
forming revisions during the browsing session. As previ- 
ously discussed, remotely stored information which is sub- 
ject to frequent or unpredictable change, such as weather 
reports, price lists, new services, etc., or which is quite 
voluminous and only infrequently accessed, should nor- 



remaimng controls on the display are greyed to indicate they to maUy not be locally stored but instead remotely accessed, 
are disabled, with the exception of the preview button and The checkbox 214 Is disabled (checked and greyed) when 
the radio buttons at 207 which allow the developer to specify the target page specified by the URL displayed at 201 is 
whether the choices made on the dialog box are to be already locally stored. 

appUcable to all occurrences of links to this target URL. or The target area of FIG. 4 also includes controls 21«18 
only to the particular link whose activation caused the Link is which enable the developer to assign a reward/penalty value 

Handling dialog box to be displayed. The "Prevent" option ^ *»rk c.j. . . ^ r 

is implemented by placing a replacement command record 
in the string list 133 which identifies the Target URL, sets the 
boolean values Search_URL to true. Search^Anchor to 
false, Search^Normal to false and Case ^Sensitive to false. 20 
Target_Page and Replacement bom contain null strings, 
unless radio buttons 207 are set to indicate that only this 
specific link is to be disabled, in which case Target_Page 
and Location are set to specify the page and character 



to each target page. Each target page is initially assigned a 
neutral default reward/penalty value of zero, but may be 
assigned a value varying from a penalty of -10 to a 
maximum reward of +10. When a browsing session is 
initiated by the first link from the root attract page, the 
session-points-remaining value is set at a predetermined 
value determined by the user entries at 510 and 512 in the 
dialog box seen in FIG. 10, discussed later. As the session 
continues, the access control system 110 decrements this 



location respectively of the beginning of the link to be 25 value by at the rate, for example, of 5 points per second for 

UlSADled. ♦* i » < . • .. . 



disabled. 

If the radio buttons 205 are set to indicate that a different 
target should be substituted for the target whose URL is 
shown at 201. the "Substitute" button is selected which 
enables a drop-down edit box 211 and browse button 213. 
When the drop-down button at the right-hand end of drop- 
down edit box 211 is depressed, the URL's of the locally 
stored pages are displayed, enabling one files of those to be 
directly. Alternatively, the URL of a local or remote page 



30 



neutral pages'* but increases the rate to 15 points per second 
for heavily penalized pages, whereas pages set to a reward 
value of +5 result in no change, and reward values of +10 
actually cause the session-points-rcmaining value to 
increase at the rate of 5 points per second. Whenever the 
accumulated points reaches zero the session is terminated by 
displaying an insert page reading **Your Time Has Expired 
Next User Please", and returning to the attract page. 
The scrollbar control 216 with the slider 217 provides a 



may be entered into the edit box 211 or the browse button 35 convenient mechanism for setting the rewardVpenalty value 

213 depressed to display a conventional filename browsing as desired, indicating to the user that viewing certain paces 

dialog box for locating desired files anywhere on the local is to be encouraged while viewing other wires is to be 

7 ubstitote " h 5dcctcd - wc originally discouraged. In this way, users who are viewingpages which 

requested URL dispUy at 201 is gjeyed and the preview the kiosk proprietor favors earn longer session^ times that 

button 203 when pressed displays the substitute file whose 40 viewing disfavored pages 

URL is shown in the edit box 211. Hie substitution of a When the developer actuates a link during the develop- 

cwterent link is implemented by placing a replacement ment session, the Link Handling dialog box seen in FIG 14 

record in the string list 133 which uses the Target and/or also provides a mechanism for requesting and identifying 

Ucation fields, as weU as die Search_URL flag, to identify the display of a transition page prior to the display of the 

*e link to be modified and places the new target's URL in 45 target page specified in the target area as described above, 

ute replacement field. The replacement command of The radio buttons allow the specify "None* to indicate that 

the -Substitute" option in Link Handling dialog box of FIG. to specify that an insert page is to be selected from the 
~ . ... . ^ collection of available insert pages, and "Selected" to indi- 

The handling of the target page identified at 201 may be 50 cate that the particular page entered into drop down edit box 



further defined using the dialog box of FIG. 4 by the 
checking checkbox 215 labeled "Link No Further" to disable 
all of the links on the target page in the manner previously 
discussed in connection with the string replacement com- 
mand Example 6. 

The target area of the dialog box of FIG. 4 also includes 
a checkbox 214 which can be checked by the developer to 
indicate that a remote web page should be stored locally on 
the kiosk computer. In that event a copy is made of the page 



223 is to be inserted. The drop down button at the right of 
edit box 223 causes the display of a drop down list of all 
insert pages in the collection of available pages from which 
a selection may be made. Alternatively, a URL may be 
55 entered directly into the edit box 223 or selected using a 
conventional filename selection dialog box activated when 
the adjoining browse button 22S is pressed. 
The duration of the inserted page may be set by entering 

. . . , . ^ , — - ~ a number in the edit box 230. This number is then placed in 

I^^l. ^ ^ WES at 201, along with copies of 60 the <META> statement along with the insertion page name 
all imbedded graphics identified by <IMG> tags. An entry is to control the dynamic loading of the original target URL 
then made in a iocailystc*ed lookup table to which the page after the display of the insertion pageas previously 
access control unit 120 refers to convert link requests described in connection with FIG 3 
directed to the original remote URL into requests directed to TT*c dialog box seen if FIG. 5 is displayed whenever the 
me new locally stored fUc, No rewriting of the links them- « user performs a right-button mouse click when the cursor is 

^ ^ M d ??T d " on a wcrd OT wheldisplayed text has been sdecUdTaTg a 

FIG. 9, HTML pages which are stored locally, including standard left-button-depressed text selection dragging 
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operation. When a word or string is selected, depressing the the dialog box of FIG. 5 as indicated at 333. If the developer 
riSt-hand mouse button produces a set of conventional right clicks the mouse on displayed anchor text, an anchor 
ootions(CoDV Cut. etc.) and the additional option Replace" image, or on whitespace. the dialog box of FIG. t i is 
S?mU the dialog box seen in FIG. 5 displayed to obtain « * DCW 
with the selected word or text appearing as i-J » X^S^^VJ^^ 
Find edit box 240. Using the check boxes at 241, 243, 245, A ™ure that ite developer does not overlook any links 
and 247. the developer indicates whether or not the stting w ^™ 0f M ^ 2ft operaUve on pages presented 
displayed in edit box 240 is to be replaced on a case sensitive %q ^ ^ ^ ^ fa advantageous to automate the task of 
basis, and whether it is to be replaced when found in normal scanning each page for Unts and automatically presenting 
displayed text, anchor text or in a URL, respectively. Hie io to mc ^eloper w h 0 may then elect the treat- 
replacement text which may be lengthy, is entered into a ment t0 ^ accorded each link. The automated development 
memo box 248 as seen in FIG. 5, The radio buttons 249 procedure illustrated by the flow chart of FIG. 9 provides 
allow the developer to specify whether all occurrences of the SU ch a mechanism. 

text in edit box 240 are to be rewritten as indicated by the automated development session depicted in FIG. 9 

dialog box. or only the specific text which was identified 15 begins with the display of the kiosk's "attract page" which 

when the dialog box was opened The dialog box seen in constitutes the root page for the hierarchy of pages which are 

FIG. 5 can also be opened by menu selection, in which case associated by hypertext links. The attract page, illustrated by 

the radio buttons 249 are greyed and disabled. The replace- the page 81 seen in FIG. 1. is advantageously stored on the 

ment command Example 2 discussed above may be pro- kiosk computer's local hard drive during normal use. In the 

duced using the String Replacement dialog box seen in FIG. 20 absence of any activity by a user of the kiosk for a prede- 

5 termined timeout duration, the kiosk computer automatically 
By right-clicking the mouse on t4 white space* (e.g., a restores the display of the attract page so that all users are 

position between words or images) of the currently dis- presented with the same beginning point, 

played page, a pop-up menu is produced which includes the Display pages which are not linked directly or indirectly 

entry "Insert Link" which, if chosen, displays the dialog box 25 to the attract page are not accessible to the kiosk user. The 

of FIG. 6. Alternatively, right clicking on existing anchor set of presentation pages which will be made available to the 

text or image causes the pop-up menu to include the option user is defined by the combination of (1) the locally stored 

"Edit Link" which, if selected, causes the dialog box of FIG. pages on the kiosk computer' s hard drive linked to the attract 

6 to be presented with the included controls already filled in; page; (2) remotely stored pages linked to those locally stored 
that is. if anchor text was selected, that text appears in the 30 pages; and (3) other remote pages to which Unking is 
memo box 251 and if an anchor image was selected, the permitted from remotely stored pages by the access control 
S.C=URL for that image appears in a drop down edit box information, including additional links, stored in the transi- 
253 Likewise, the URL of the target of the link is displayed tion list 111 and the string list 133 seen in FIG. 2. The 
in a drop down edit box 257. development session, typically carried out by * CG ™P** 

The data gathering functions provided by the dialog boxes 35 such as the authoring computer 30 seen in FIG. 1 which is 

seen in FIGS. 4-6 of the drawings is further illustrated by the remote from but in communication with the kiosk computer 

flow charts seen in FIGS. 7 and 8. (s), accordingly consists of the steps of making available the 

FIG. 7 illustrates the operation of the dialog box of FIG. locally stored pages, establishing a connection via the Inter- 

4. The dialog box is displayed in response to the issuance of net (or a similar connection) to one or more remote servers 

a linking request by the development system web browser as 40 which store the remotely stored pages, and evaluating those 

seen at 301 in FIG. 7. The radio buttons 205 of FIG. 4 accept available pages and the links imbedded in each to develop 

a selection within the decision box 303 in FIG. 7. If a the access control found in the two lists and to specify which 

substitution is selected, the developer supplies the URL of pages accessed via the network are to be locally stored and 

the new target at 305 using the edit box 211 seen in FIG. 4. which are to remain accessible only by a network access, 

impropriate entries are then made into the string list seen at 45 Thus, at entry point 401 seen in FIG. 9. the development 

133 in FIG. 133 as seen at 305. 307 and 309 in FIG. 7. session begins with the root attract page being the current 

The lower portion of the flow chart seen in FIG. 7 page undergoing evaluation. At step 402, each page is 

illustrates the procedure followed to utilize the entries in the scanned for the presence of links at 403 unless that page has 

transition display section of the dialog box seen in FIG. 4. been previously identified as being a page from which no 

Hie decision block 311 of FIG. 7 accepts the selection made 50 more further linking is to be permitted as previously 

by the user using the radio buttons 221 of FIG. 4. Based on explained in connection the checkbox 214 shown in FIG. 4. 

the remaining data entered on in the transition display If metinkmgbtobeprombitedrxomalllinks on the current 

section of the dialog box, an appropriate record may be page, the page is processed at 404 by posting to the string list 

added to the transition list 1U seen in FIG. 2 as indicated at 133 a replacement command record having a Target_Page 

313. 315, 317 and 319 in FIG. 7. 55 field set to the URL of the current page and the boolean flag 

T^e flow chart seen in FIG. 8 illustrates the procedure bit Disablejagewide set to TRUE. As previously noted in 

followed to utilize the information entered in the dialog connection with the string replacement command Example 

boxes shown in FIGS. 5 and 6. As described earlier, right 6, the HTML rewrite mechanism 130 seen in FIG. 1 

clicking the mouse on the displayed page displays a pop-up responds to this command by replacing each the linking tag 

menu which supplies the developer with the option of 60 in an HTML being accessed with the imbedded anchor 

replacing displayed text or inserting a tag at the position in information alone, thereby disabling each link and removing 

the displayed page indicated by the mouse click. If the the highlighting or other visually linking cue which would 

mouse is clicked on a word or on a selected string which is otherwise be added by the browser to identify the presence 
not highlighted anchor text as determined at decision block of these links. Note that the command created at step 404 

325. the dialog box of FIG. 5 is displayed to provide the 65 eliminates the need for the user to individually enable or 

information collected in steps 327-330 of FIG. 8. disable links on a page which may contain large numbers of 

Alternatively, a menu selection can also invoke the display links. 
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When linking from the current page is permitted, each 
link is processed by the content developer as indicated at 
step 403-409 in FIG. 9. The current hypertext page is 
scanned, beginning at the start of the document, for the first 
(next) hypertext link to another page. If an imbedded link is 5 
found, as indicated by the "Yes" result branch at decision 
block 405. the link handling dialog box depicted in FIG. 4 
(and the detailed flowchart of FIG. 7) is displayed for a 
response by the developer as seen at 407. As previously 
discussed, the link handling dialog box permits the devel- 10 
oper to preview the target page specified by the detected link 
and to choose whether to accept (OK) the link, prevent the 
link from being activated, or substituting a link to a different 
page as indicated by decision block 409 in FIG. 9. In 
addition, as seen in the dialog box of FIG. 4, the content is 
developer may specify whether a given target page is to be 
locally stored if currently accessed from the network, and 
whether further links from that page are to be disabled as a 
group (by checking checkbox 214 on FIG. 4) or individually 
processed. 2 o 

If the developer elects to prevent an individual link by 
selecting either "Prevent Here" or "Prevent Everywhere** 
using the radio buttons 205. the string list 133 is updated as 
previously discussed in connection with step 309 seen in 
FIG. 7. and a return is made to the page scan step 403 to 25 
search for the next link on the current display page. 

If the developer accepts the imbedded link, or substitutes 
a different link, the currently displayed page identification is 
pushed into a software stack as indicated at step 411. the 
newly specified target becomes the current display page as 30 
seen at step 413. and scanning of that the new current page 
is begun by returning to the scanning step 403. 

When there are no further links to evaluate on the current 
page, as indicated by the No branch from decision block 
405. the user is given the opportunity at step 417 to modify 35 
the displayed text using the string replacement dialog box of 
FIG. 5 as seen at step 419. which may be activated at step 
417 either by menu request or by right clicking on a word or 
selected text in the displayed document as previously dis- 
cussed The replacement string specified in dialog box 5 is 40 
also evaluated at step 421 to determine if it contains a link 
to a hypertext page and, if so, the identified link is evaluated 
in the usual fashion by returning control to the dialog box of 
FIG. 4 as indicated by branch 420. Otherwise, the user is 
given the opportunity the enter further replacement strings 45 
as indicated by branch 422. 

In a similar fashion, as indicated at decision block 431. the 
user is also given the opportunity to use a right mouse click 
to further edit an existing link, or add an entirely new link, 
by right-clicking on white space or a link anchor as indicated so 
at 325 and 341-343 of FIG. 8 to invoke the link description 
dialog box of FIG. € as seen at step 432 of FIG. 9. If the 
developer elects to define a new link, as indicated by the yes 
branch 435 from decision block 433. control is returned to 
step 407 to enable the dialog box of FIG. 4 to be used to add 55 
a transition display if desired. Otherwise, the display of the 
current page is continued such that the developer can add or 
modify additional links or add additional string replacement 
commands. 

When the user indicates that no additional editing of the 60 
current page is required, and when all remaining hypertext 
links on the current page have been authorized, no further 
processing of the current page is required as indicated at 
branch 440. the page which contained the link to the current 
page is popped from the stack to become the new current 65 
page as indicated at step 441. If the stack is empty, indicating 
that all links from the attract page have been resolved, the 
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development session is concluded; otherwise, the page 
popped from the stack becomes the new current page as 
indicated at step 413 and scanning of that page resumes at 
step 403 which searches for the next unresolved link. 

FIG. 10 of the drawings illustrates the on-screen appear- 
ance of the dialog used to obtain information from the user 
which may be employed to limit the duration of a given user 
session while FIG. 11 is a flow chart which illustrates the 
manner in which this information is utilized to control the 
session duration. The dialog box of FIG. 10 is displayed on 
request by the user, or automatically the beginning or end of 
each development session, and includes the following con- 
trols: an edit box at 510 which accepts a numerical quantity 
indicating the number of minutes each session may continue 
before links to further pages are disabled by employing the 
HTML rewrite mechanism seen at 130 in FIG. 2 to rewrite 
all link tags as anchor information alone; and an edit box 512 
which accepts a numerical quantity indicating the number of 
minutes each session may continue before the session is 
mandatorily terminated by returning the user to the home 
page, accomplished by utilizing the transition display 
mechanism 133 of FIG. 2 to issue a URL request for the 
home page. 

Note that the URL request which forces the return to the 
home page may be accompanied by a predecessor transition 
display page which displays a warning notice, e.g., *TTME 
EXPIRED. NEXT USER PLEASE.". In addition, to further 
discourage the current user from continuing to use the 
display unit, the home page may require the mandatory 
completion of an HTUML "registration" form which 
requests identification data from a user, such as name, 
mailing address, phone number, date of birth, etc. This 
demographic data is then recorded and may be used to 
produce a user evaluation number. By way of example, (he 
evaluation number may be generated by a combination of 
the user's age and zip code, generating a maximum valua- 
tion number for adults living in a particular area and a 
minimum valuation number for children living far from the 
kiosk location. 

As illustrated at 514 in FIG, 10, the developer uses two 
list boxes to develop session time adjustment profiles based 
on the time of day when the display unit is being displayed 
(left hand list box at 514) and the user valuation number 
produced from the demographic data as noted earlier (the 
right hand list box at 514). In mis way, session durations 
greater than the default values entered at 510 and 512 are 
allowed at those times during the day when little usage is 
likely, and reduced session times during the busiest hours. 
Similarly, using the adjustment profile recorded in the right 
hand list box at 514. adjustments to the session times may 
be made based on the user valuation number. Changes to 
individual entries in either the time-of-day adjustment pro- 
file in the left list box at 512 or the user valuation profile in 
the right list box at 512 arc made by clicking on an 
individual item and changing the adjustment value in the 
spinner-driven edit box at 516. 
Session Tuning and Logging Mechanism 

Session timing is accomplished by an interrupt or timer 
driven routine as illustrated in FIG. 11. Upon each occur- 
rence of a system time interrupt, the routine is entered at 521 
and a count value CNT is incremented. If COT is evenly 
divisible by a value IC (with IC having a value selected such 
that me routine beginning at 527 is entered every 10 
seconds, for example), a session count value is incremented 
(or decremented) by PageVaiue at 527, incremented (or 
decremented) by UserValue at 529, and incremented or 
decremented by HmeValue at 531. The session count value 
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SC is initialized to zero at the beginning of every new ended by branching to 539 such that the attract (home) page 

session and counts upward toward limit vaiues LinkVal, is again displayed for viewing by the next user, 

which establishes a session duration threshold at which Information Exchange 

further linking is terminated, and EndVal. which establishes The sequence of events which occur during the overall 

a session duration threshold at which the session is termi- 5 operation of a display unit, such as the kiosk 10 seen in FIG. 

nated entirely. PageValue is a positive or negative integer 1. is depicted by the flow chart of FIG. 12. 

which adjusts the amount by which SC changes (upwardly Before the display unit is first operated, it must receive the 

or downwardly) based upon the value entered by the user for locally stored disputable information files as well as the 

the current page being viewed when that page was ranked control structures developed as described in connection with 

using the controls 216-218 in the dialog box seen in FIG. 4. to FIG. 9 consisting of the string list seen at 133 in FIG. 1, the 

UserValue is a positive or negative integer reflecting the transition list seen at 111 in FIG. 1, and the lookup table 112 

weight given to the user valuation in the right hand list box seen if FIG. 1. As previously noted, these files are advan- 

514 of FIG. 10, with the valuation number being derived tageousry created using the interactive content authoring 

from the demographic data entered during user registration system described above at a remote authoring station, such 

as discussed above. Finally, the count SC is adjusted by 15 as the computer 30 seen in FIG. 1, and are transferred to the 

TimeValue comprising the combination of a fixed positive display unit's local storage by a file transfer via the dialup 

base value which reflects the passage of time as adjusted by telephone system or by Internet FTP transfers as seen at step 

a time-of-day adjustment obtained by comparing the current 571 in FIG. 12. 

time of day with die time-of-day profile value entered by the Each session begins, as indicated at 572, by initializing 

developer in the left handlist box 514. Together. PageValue. 20 the CNT, SC and LAST URL variables, by turning off the 

UserValue and TimeValue quantities provided by the devel- link disabling mechanism if it has previously been turned 

oper control the rate at which SC advances toward the ON as described in connection with step 536 seen in FIG. 11, 

thresholds LinkVal and EndVal which are set by the devel- and by issuing a URL request for the display of the home 

oper's entries at 510 and 512 respectively as seen in FIG. 10. (attract) page. As previously noted, the home page or its 

When SC is greater than LinkVal as determined at 533, 25 necessary successor advantageously includes a registration 

the link disabling process in HTML rewrite mechanism 130 form which is directed to a local CGI (Common Gateway 

is turned ON as indicated at 536. If the session count value Interface) processing facility which appends a record to a 

SC is also larger that EndVal as determined at test 538. the file of records containing user identification information as 

session is terminated as indicated at 539. indicated at 574 and 575 in FIG. 12. 

The timer driven interrupt handling routine seen in FIG. 30 During me course of the session, as each new page is 

11 further includes a mechanism for logging session usage. accessed, the URL for that page, its start time, and an 

Each time the interrupt count CNT is divisible by the integer identifying number specifying the current user is appended 

MC (which is selected such that the test at 525 is performed to a log file of URL usage records as indicated at 576 and 

once per second, for example), a test is performed at 525 to 577 (previously describe in connection with step 526 in FIG. 

determine if the current page being displayed has changed 35 11). When the session ends by a timeout condition being 

since the last test at 525. a determination made by comparing detected as indicated at 578 (tests 538 and 540 in FIG. 11), 

the URL of the current page with the string LASTURL saved if the display unit is determined to be idle at 580 (based on 

during the last detected transition. If URL is not equal to test 540 in FIG. 11), the display unit makes use of the idle 

LASTURL. an entry is appended to a log file consisting of time to perform housekeeping information transfers as indi- 

records each comprising the new URL. the time of day at 40 cated at 590-596 in FIG. 12. First a link is established to a 

which the page designated by the URL was first displayed, supervisory computer (typically a host computer on the 

and an integer identifying the current user by speciAng the Internet which can receive information using FTP or SMTP 

record number for that user in a file of registration records transfers) at 590 and thereafter the previously untransmitted 

accumulated for the user from CGI processing of the home portion of the usage record file is transmitted as indicated at 

page registration form. In mis way, a log file is maintained 45 592 and the previously untransmitted user records are trans- 

from which the entire viewing history for each user may be mitted at 594. 

reconstructed, the amount of usage for each HTML docu- Then, as indicated at 596 in FIG. 12, the records in the 

ment (total occurrences and average viewing time), and data lookup table are processed sequentially by transmitting an 

correlating the demographic data with the available content. "if modified since" message to the server holding each file 

Such data is of particular value to the content developer 50 designated by an origination URL in the lookup table. If it 

since it enables the developer to identify pages which were is determined that the file identified by the origination URL 

of interest to users, pages which were frequently accessed has been modified since the locally stored copy was created 

from the network and are hence candidates for local storage, (perhaps by the authoring computer) or last updated by the 

etc As noted earlier in connection with FIG. 1 of the individual display unit, the newly revised copy is accessed 

drawings, this demographic and usage log data may be 55 and stored after being passed through the HTML rewrite unit 

transmitted to the authoring computer by establishing a file 130 which alters the newly stored local copy in accordance 

transfer connection via a conventional modem-to-modem with the commands contained in the string list 133. 

route over the dialup telephone lines, of by using the Internet The mechanism for updating stored files which originated 

to perform an FTP or SMTP transfer. from remote locations is illustrated schematically in FIG. 13 

When the current URL is found at test 525 to be 60 of the drawings. The left hand flow chart in FIG. 13 

unchanged from LASTURL, a further test is performed at illustrates the manner in which the lookup table, shown 

540 to determine if the current time exceeds LT, a time value generally at 600, is used to redirect URL requests for 

saved at 526 when the current URL was first detected, by remotely stored documents such that they instead retrieve 

more than a idle time value Q. When Time>LT+Q. it is locally stored copies. The right hand flow chart of FIG. 13 

established mat the current page has been on screen for more 65 shows how the lookup table 600 is employed to periodically 

than time Q with no user activity; consequently, since the update the stored information so that it takes into account 

display unit is apparently not being used, the session is modifications to the files as they exist in the remote servers. 
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Both of the routines illustrated in the flow charts of FIG. 
4 are executed by the transition display control mechanism 
seen at 113 in FIG. 2. The routines manipulate and respond 
to values stored in lookup tabic 600 which consists of a 
plurality of entries, one for each remote file stored in local 
storage, each entry consisting of four fields: an originating 
URL field 603, a Chck field 604 storing a time stamp 
indicated when the entry was last validated, a Mod field 605 
storing a lime stamp indicating when the corresponding 
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Note that, as an alternative to performing the validation 
routine at the display unit as indicated at 596 in FIG. 12. a 
supervisory computer may be used to periodically verify the 
integrity of the local files stored in the individual satellite 
display units by performing the validation routine at inter- 
vals to identify files to be updated. When such testing reveals 
that a locally stored file should be updated, the supervisory 
computer may retrieve the modified file from the remote 
server and then transfer that file to each satellite display unit 



local file was stored or last updated, and a local URL field to when that unit establishes contact with the supervisor; that 

607 specifying the local storage location of the local copy of is. instead of performing its own validation at 596. the 

* c fiJc * satellite instead accepts the transfer of identified update files 

When the control unit 113 receives a URL request which from the supervisor. eUminating the need for the individual 

specifies a remotely located file, that file may have been display units to independently test their local files against the 

locally stored at the request of the content developer (using 15 originals, and further eliminating the need for the satellite 



the Make Local checkbox 215 seen in FIG. 4), in which case 
the a copy of the file originally designated by an originating 
URL is placed in local storage at a location specified by a 
local URL in field 607. 

During the operation of the display unit, when the user 20 
activates alinkto generate a URL request seen at 109 in FIG. 
2, the routine beginning at the entry point A at 609 is entered. 
If the URL contained in the request specifies a remote URL, 
a search is conducted to determine if the requested remote 



URL is in the lookup table 600, indicating that a local copy 25 scope of the invention, 
is available. To speed the search, the entries in lookup table 
600 arc advantageously sorted into order by originating 
URL. permitting a binary search for a matching entry to be 
conducted as indicated at 611. If a match is found, the local 
URL from field 607 is substituted for the URL in the request 30 
being processed as indicated at 615 to redirect that request 
to the local copy. The lookup routine concludes at exit point 
B indicated at 617 in FIG. 13. 

When the display unit is idle and the routine at 596 is 
called as indicated in FIG. 12 to verify the integrity of the 35 
stored files against the remote originals, the routine begin- 
ning at entry point C as seen at 619 in FIG. 13 is called. Each 
time the routine is entered, one of the entries pointed to by 
a counter value FP is checked. If the entry pointed to by FP 
contains a time stamp in the Chck field which differs from 40 
the current time by less than W as indicated by the test 621, 
no further updating is needed and the routine terminates at 
exit point D seen at 622. The value of W specifies the 
frequency at which updating is performed. Thus, if W is set 
to a value equivalent to 30 minutes, the entries in table 600 45 
are checked until an entry is found that was check less than 
30 minutes previously. 

The validation performed at 623 is performed by issuing 
an if -modifiedr since message to the server specified by the 
URL in the originating URL field 603 pointed to by FP, 50 
together with a specification of the time stamp found in the 
Mod field 605 of that entry. If the remote server responds 
with an indication that the original file has been modified 
since the time indicated by Mod, the modified version is 
retrieved and stored locally, as indicated at 627, and the table 55 
entry pointed to by FP is updated with the current time value 
in both the Mod field 605 and the Chck field 604. as well as 



computers to maintain the Chck and Mod fields in the 
lookup table 600. these fields being maintained solely by the 
supervisory computer which performs the routine shown at 
the right in FIG. 13. 

It is to be understood that the specific embodiment of the 
invention which has been described above is merely illus- 
trative of one application of the principles of the invention. 
Numerous modifications may be made to the apparatus and 
methods described without departing from the true spirit and 



What is claimed is: 

!• A system for displaying hypertext information 
comprising, in combination. 

a supervisory computer for generating a control informa- 
tion file and one or more hypertext document files, and 
at least one display unit comprising, in combination: a 
local processor, a display screen, input means for 
accepting data requests from a user, communications 
facilities for receiving said control information file and 
said hypertext document files from said supervisory 
computer, and local storage means for storing said 
control information file and said document files, 
wherein said control information file includes at least 
one item which specifies a selected document file in 
said local storage means and the remote location of an 
original file from which said selected file was copied 
and wherein said local processor includes local file 
validation means comprising: 
means responsive to said one item in said control infor- 
mation file for retrieving an attribute of said original 
file from said remote location via cornmunications 
facilities, 

means for using said attribute to determine whether said 

original of said selected file has been modified, and 
means for replacing said selected file with a new copy of 
said original transferred from said remote location via 
said telecommunications facilities when said means for 
using said attribute indicates that said original has been 
modified. 

2. A system as set forth in claim 1 wherein said local 
processor further including means for detecting an idle 
condition when no data requests are being received from a 
user and means for activating said local file validation means 



placing the new local storage URL (if necessary) in field 

607. If no updating is necessary, the Chck field 604 alone 

receives the current time value. So long as the display unit 60 in response to a detected idle condition 

continues to be idle as indicated by the test at 630, the testing 3. A system as set forth in claim 1 wherein said local file 

of the validity of the entries in table 600 can continue and FP validation means further comprises means for recording the 

is incremented at 629 to check the next entry. If a user has prior time at which said selected file was last compared with 

activated the unit, the checking is terminated by exiting to said attribute and means for inhibiting the operation of said 

point D at 622. The value FP is retained so that, when the 65 means for retrieving an attribute of said original file when 

validation routine is again entered at 619, checking will less than a predetermined period has elapsed since said prior 

continue with the oldest unchecked entry. time. 
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4. A system as set forth in claim 1 wherein said control 
information file comprises a plurality of entries each of 
which associates the identification of a specific one of said 
document files in said local storage means with the remote 
location specification of an original file from which said 5 
specific file was copied, and wherein said local processor 
further includes means responsive to a data request from a 
user which includes a particular remote location specifica- 
tion for displaying that document file in local storage which 

is associated by an entry in said control information file with 10 
said particular remote location specification. 

5. A system as set forth in claim 1 wherein said local 
processor further includes means for recording each data 
request received from said user to form a log file and means 
for transferring said log file to said supervisory computer via 15 
said telecommunications facilities. 

6. A system as set forth in claim S wherein said local 
processor further includes means for further recording the 
time when each of said data requests is received from said 
user in said log file. 20 

7. A system as set forth in claim 5 wherein said local 
processor further includes means for further recording the 
identity of each of said user in said log file. 

8. A system as set forth in claim 1 wherein said control 
information file includes data associating at least one of said 25 
document files with a remote record locator value specifying 
the location of an original document in a remote computer 
from which said one document file was copies, and wherein 
said local processor includes means responsive to a data 
request containing said remote record locator value for 30 
displaying said one document file from said local storage 
means. 

9. A system as set forth in claim 8 wherein said local 
processor further including means for detecting an idle 
condition when no data requests are being received from a 35 
user and means for activating said local file validation means 

in response to a detected idle condition. 

10. A system as set forth in claim 8 wherein said local file 
validation means further comprises means for recording the 
prior time at which said selected file was last compared with 40 
said attribute and means for inhibiting the operation of said 
means for retrieving an attribute of said original file when 
less than a predetermined period has elapsed since said prior 
time. 

11. A system as set forth in claim 8 wherein said local 45 
processor further includes means for recording each data 
request received from said user to form a log file and means 
for transferring said log file to said supervisory computer via 
said telecommunications facilities. 

12. A system as set forth in claim 11 wherein said local 50 
processor further includes means for further recording the 
time when each of said data requests is received from said 
user in said log file. 

13. A system as set forth in claim 11 wherein said local 
processor further includes means for further recording the 55 
identity of each of said user in said log file. 

14. Display apparatus for displaying a sequence of items 
of hypertext information from a set of such items designated 
by an author, the set of items including locally- stored copies 

of remotely-located original hypertext items and the appa- 60 
ratus comprising: 

a link rewrite specification made in response to a first 
input from the author, the link rewrite specification 
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indicating at least links containing location information 
for remotely-located original hypertext items that are to 
be rewritten to contain location information for the 
locally-stored copies; 

a link rewriter which automatically rewrites links in 
hypertext items fetched for display as specified by the 
link rewrite specification; and 

a hypertext item fetcher which responds to activation of a 
link by a user of the display apparatus by fetching the 
hypertext item at the location specified by the link. 

15. Display apparatus for displaying a sequence of items 
of hypertext information from a set of such items designated 
by an author, the set of items including locally- stored copies 
of remotely-located original hypertext items and the appa- 
ratus comprising: 

a local copy specification made in response to an input 
from the author, the local copy specification containing 
location information for remotely-located original 
hypertext items, location information for the locally- 
stored copies, and consistency checking information 
for determining whether a locally- stored copy whose 
location information is in the local copy specification 
should be checked for consistency with its original 
hypertext item; and 

a consistency checker which checks the consistency of the 
locally- stored copy when the consistency-checking 
information so indicates, and if the locally-stored copy 
is inconsistent, replaces the locally-stored copy with a 
new copy of the remotely-located original. 

16. The display apparatus set forth in claim 15 further 
comprising: 

a hypertext item fetcher which responds to activation of a 
link by a user of the display apparatus by using the local 
copy specification to examine location information in 
the activated link to determine whether there is a 
locally-stored copy of the hypertext item specified by 
the location information and if there is. fetching the 
local copy instead of the remotely-located original. 

17. The display apparatus set forth in claim 15 further 
comprising: 

a link rewrite specification made in response to a first 
input from the author, the link rewrite specification 
indicating at least links containing location information 
for remotely-located original hypertext items that are to 
be rewritten to contain location information far the 
locally-stored copies; 

a link rewriter which automatically rewrites links in 
hypertext items fetched for display as specified by the 
link rewrite specification; and 

a hypertext item fetcher which responds to activation of a 
link by a user of the display apparatus by fetching the 
hypertext item at the location specified by the link. 

18. The display apparatus set forth in claim 17 wherein: 
the hypertext item fetcher further responds to activation of 

a link by a user of the display apparatus by using the 
local copy specification to examine location informa- 
tion in the activated link to determine whether there is 
a locally-stored copy of the hypertext item specified by 
the location information and if there is, by fetching the 
local copy instead of the remotely-located original. 

* * * * * 
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[57] ABSTRACT 

A method for financing a supply of goods (a supply chain) 
from a supplier to a buyer in which the buyer has a lower 
cost of funds than the supplier. According to the method, the 
buyer generates a purchase order for the goods which is 
forwarded to the supplier who in turn ships the goods to the 
buyer. The supplier sends an invoice to the buyer which 
stores the invoice data in a database. The financing institu- 
tion electronically accesses the database to retrieve the daily 
invoices. The financial institution then calculates the financ- 
ing applicable to the shipped good and forwards a payment 
to the supplier. Upon maturity of the financing, the buyer 
settles with the financial institution by remitting the gross 
proceeds. 
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1 

SUPPLY CHAIN FINANCING SYSTEM AND 

METHOD 

FIELD OF THE INVENTION 

The present invention relates to financing systems and 
methods and more particularly to a system and method for 
financing a supply of goods in a supply chain. 

BACKGROUND OF THE INVENTION 

Historically, working capital financing had been a one 
transaction process (from vendor to buyer, or supplier to 
customer) and usually involved only a single balance sheet 
or asset class. This method of capital financing is explained 
in connection with FIG. 1. FIG. 1 illustrates a traditional 
vertically integrated manufacturing processes. Raw materi- 
als 10 from a supplier were delivered to a factory 20 which 
produced finished goods 30 from the raw materials 10. From 
a financier's point of view, the only risk it had to understand 
was whether the manufacturer 20 could profitably transform 
the raw materials 10 into finished goods 30 that consumers 
wanted to and could afford to buy. Furthermore, this model 
only involves financing a single entity, the manufacturer 20. 

In today's global economy, an intricate web of interde- 
pendent players make up the international supply system, 
requiring more sophisticated methods of coordination and 
finance. This complexity challenges the current methods and 
assumptions, making it more difficult for the financier to 
gauge the risk involved. 

Furthermore, in the conventional supply chain financing, 
individual decisions are made at the enterprise level regard- 
ing the working capital finance structure to support opera- 
tions. Each company in the supply chain has varying degrees 
of incentives to pay late and collect funds early, and to push 
as much inventory onto the balance sheets of its counter- 
parties. 

A combination of three emerging technologies has 
enabled the development of the present invention and its 
application to supply chain financing. These technologies 
are Supply Chain Management (SCM) techniques, elec- 
tronic commerce (EC), and financial market technology. 
SCM has been defined as the management of flows, includ- 
ing materials, information, and money. Before SCM tech- 
niques were introduced, the size of buffer stocks maintained 
by a manufacturer or supplier were large, and even then, 
these buffer stocks often could not accommodate the peak 
seasonal requirements of customers. The introduction of 
SCM has smoothed out material flows, and this in itself has 
reduced the working capital expense associated with the 
high inventories of yesterday. 

The second enabling technology that supports the devel- 
opment of the present invention is the transformation of 
electronic commerce (EC). While EC has been used for 
many years, start-up costs have been quite high, and many 
potential applications have therefore been excluded. With 
the development of company intranets and browser-based 
applications, new uses of business to business electronic 
commerce are burgeoning. Savvy financial institutions (e.g., 
banks) are migrating their information-based products from 
proprietary in-house developed software to browser-based 
intranet applications. Accordingly, these savvy institutions 
are now positioned to access their clients'supply chain data 
from their clients'electronic commerce and enterprise 
resource planning (ERP) systems in order to provide financ- 
ing based on those data. 

Tne third factor that permits the optimization of the 
present invention is the growth of investor appetite for 
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securities linked to specific cash flows. This form of invest- 
ment is distinct from investments in securities linked to the 
risks and rewards of companies themselves, such as equity 
and debt securities. 

5 In light of the problems associated with the conventional 
methods of supply chain financing, and in view of the 
emergence of the above described enabling technologies, it 
is an object of the present invention to reduce the finance 
costs associated with the supply chain and to free the 

30 movement of goods across the balance sheets of supply 
chain partners. 

SUMMARY OF THE INVENTION 

The present invention, Supply Chain Finance (SCF), can 
be most easily thought of as "just in time money". It is the 
financial equivalent of materials planning "just in time" 
(JIT) and its benefits are very similar. Like JIT, the present 
invention seeks to eliminate inefficiencies that arise when 
2Q trading partners do not coordinate their demand require- 
ments. 

In many cases, a supplier's cost of funds is greater than its 
buyer's cost of funds. The present invention enables the 
provision of financing to a supplier at the buyer's lower 

25 finance cost. The cost savings can be used to extend the 
buyer's days payable outstanding, resulting in an improve- 
ment in its Shareholder Value Added (SVA). In contrast to 
the prior art financial technique of factoring, the financing of 
the present invention is usually mandated by and arranged in 

30 conjunction with buyer — not the seller. 

Furthermore, the financing of the present invention can be 
arranged without recourse to the seller, enabling off-balance 
sheet treatment for the seller. Thus, the SVA for both entities 
can be improved and the financing takes place at the lowest 
35 possible cost for both parties. 

As described above, SCM techniques have been devel- 
oped to coordinate complex supply chain interrelationships. 
However, one hidden cost of many SCM techniques has 
been to place greater reliance on suppliers to hold inventory. 

4 0 Many suppliers of United States companies, particularly 
those located in emerging market countries, have higher cost 
of funds than do their U.S. customers. The present invention 
eliminates this inefficiency by ensuring that the capital cost 
associated with the asset conversion cycle of any given 

45 supply chain is the lowest possible. 

The present invention takes advantage of the new avail- 
ability of low cost electronic commerce links between 
buyers and their financial institutions. These links are used 
by the institution to access the data contained in the buyer's 
50 enterprise resource planning (ERP) systems. With this data 
in hand, the institutions are able to evaluate, develop and 
offer highly structured financial products tailored to the 
clients'dynamic supply chain capital requirements. 

55 BRIEF DESCRIPTION OF THE DRAWINGS 

For the purpose of illustrating the present invention, there 
is shown in the drawings a form which is presently 
preferred, it being understood, however, that the invention is 
not limited to the precise arrangement and instrumentality 
shown. 

FIG. 1 illustrates the conventional vertically integrated 
manufacturing process; 

FIG. 2 depicts an Accounts Payable Financing application 
65 in accordance with the present invention; 

FIG. 3 is a graph illustrating the financial advantages of 
the use of the present invention; 
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FIG. 4 is a Trade Cycle Map illustrating the assets 
attributed to the participants in the supply chain; and 

FIG. 5 depicts a Vendor Financing in accordance with the 
present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

One application of the present invention is Accounts 
Payable (AP) Financing which is illustrated in FIG. 2. As 
illustrated in this Figure, there are three entities involved in 
the essential features of the supply chain financing of the 
present invention, the supplier or vendor 210, the buyer 220 
and the financial institution or advisor 230. In a preferred 
embodiment of the present invention, the financial institu- 
tion 230 is a bank and the buyer 22 is a client of the bank. 

Prior to actually implementing the present invention, the 
parties involved must evaluate the potential saving which 
can be expected from using the Supply Chain Financing of 
the present invention. This evaluation process typically 
begins with the buyer 220 hiring the financial advisor 230. 
The financial institution 230 uses the Trade Cycle Map (FIG. 
4) the Supply Chain Financing Formula (described below) 
and data provided by the buyer 220 to determine whether the 
potential savings justify expense of proceeding. 

Hie financial advisor 230 reviews the electronic com- 
merce infrastructure among the buyer 220 and its trading 
partners 210. Although only a single trading partner 210 has 
been depicted in FIG. 2, the present invention is clearly 
applicable to multiple trading partners 210 of a buyer 220. 
In fact, once the setup for the present invention described 
below has been completed, the buyer will actually experi- 
ence increased savings with the expansion of the supply 
chain financing to additional trading partners 210. 

If the above evaluation determines that there is sufficient 
financial benefit, the bank 230 makes recommendations on 
the structure and implementation approach, taking into 
account the client's 220 relationships with its trading part- 
ners 210 and the client's other non-financial objectives. The 
financial advisor 230 conducts interviews with the trading 
partners 210 in order to validate the supply chain assump- 
tions used above in the application of the Supply Chain 
Savings Formula and to understand other non-financial 
objectives and business values which may impact the imple- 
mentation of the present invention. If the results of the 
interviews are all favorable, and the parties agree to proceed, 
there are several technical, administrative and legal pro- 
cesses which must be established. 

The following set-up procedures are applicable to "true" 
Accounts Payable Financing in which the buyer accepts 
responsibility for the payment of the underlying merchan- 
dise. The buyer 220 in conjunction with the financial advisor 
230 determine the advance financing rates which are appli- 
cable for each of the participating vendors 210. The appli- 
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client has accepted good from the supplier. Typically, the 
client 220 vouchers the supplier's invoice upon its accep- 
tance of the goods. The rules established in the typical case 
would therefore indicate that a vouched invoice (or account 
payable) indicates that the buyer 220 has accepted the goods 
and payment is due to the supplier 210. The rules would 
additionally set forth the manner in which the financial 
institution 230 can properly identify vouchered invoices. In 
conjunction with the acceptance rules, the client 220 agrees 
to pay the financial institution 230, acting on behalf of the 
seller 210, upon maturity of the underlying financing once 
the financial institution has acted upon a properly identified 
acceptance by the client 220 (e.g., a vouchered invoice). 

Additional provisions in the agreement between the client 
220 and the financial institution 230 are: an agreement as to 
the method and form for resolving post acceptance disputes 
(usually in the form of a put to the client 220 of the 
underlying asset); and establishment of reliance on the 
selected method of communication (this will typically place 
no liability on the part of financial advisor 230 to advance 
funds in the event of communications/software failure). 

Having resolved the legal issues, the process turns to 
addressing the technical issues of implementing the present 
invention. The main technical requirement of the present 
invention is the establishment by the financial institution 230 
and the client 220 of extra/intra/internet dial-up and logon 
access by the bank 230 to the client's 220 electronic com- 
merce and enterprise resource planning (ERP) systems such 
as the client's account payable system. In general, most 
buyers 220 will already have electronic accounting and 
management systems in place and the above process is 
merely a matter of providing electronic access to these 
systems by the financial institution 230. Of course, all of the 
appropriate security measures for the provision of this 
access (e.g., passwords . . . ) should be put in place. 

Once all of the above described evaluation and setup has 
been completed, the parties are ready for the actual imple- 
mentation of the financing. In the Accounts Payable example 
depicted in FIG. 2, the buyer 220 desires to purchase goods 
from the supplier 210. To initiate the purchase, the buyer 
issues a request for goods, e.g., a Purchase Order (PO) in 
step 235 of the process. In a preferred embodiment, the PO 
235 is issued from the buyer 220 to the supplier 210 through 
an electronic link 240 such as the internet or other electronic 
data interface. Alternatively, the PO 235 can be issued 
through traditional mail, voice or facsimile channels, 
although these methods will inherently slow the process, be 
less reliable and less conducive to tracking and verification. 
Regardless of the method of transmittal of the PO 235, the 
buyer 220 updates its ERP system to reflect the issuance and 
terms of the PO 235. 

In response to its receipt of the PO 235, the supplier 210 
ships 245 the goods to the buyer 220 in anticipation of being 



cable advance rates for each of the vendors 210 will vary 55 paid (to be discussed below). In conjunction with shipping 



depending of the particular circumstances of the vendor 210 
and the relationship between the vendor 210 and the buyer 
220. A vendor profile is then established for each vendor 
210. The vendor profile includes, for example, the payment 
terms and advance rates established for the particular ven- 
dor. The vendor profile is used in the day-to-day processing 
involved in connection with the supply chain financing of 
the present invention. 

From a legal standpoint, an agreement must be reached 
between the financial institution 230 and the client 220. One 
key provision of the agreement includes establishing the 
rules by which the financial institution can identify when the 



245 the goods, the supplier 210 also transmits 250 invoice 
data to the buyer 220. Again, in a preferred embodiment, the 
invoice is sent 250 to the buyer 220 over the electronic link 
240, but can be transmitted manually (by mail, voice or 
60 facsimile). Alternatively, the shipment 245 of the goods 
(transfer of title/risk) can be established through the buyer's 
220 receipt of the goods at one of its facilities (e.g, through 
dock or warehouse receipts). 

Regardless of the method by which the shipment 245 of 
65 the goods is verified, the buyer 220 updates its ERP system 
to reflect the receipt of the goods. The buyer 220 then 
matches the delivery/invoice data to the PO data correspond- 
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ing to the delivery. If the acknowledgement data does not 
meet the buyer's 220 payment rules, then adjudication is 
required between the client 220 and the vendor 210 in order 
to determine the value, if any, of shipped goods which are 
eligible for financing. If the acknowledgement data meets 
the client's 220 payment rules, then the buyer 220 may 
deduct any credits due the buyer 220. Once the validity of 
the invoice data has been established, the buyer 220 indi- 
cates its acceptance of the goods in accordance the manner 
established by the rules between the buyer 220 and the 
financial institution 230. In the preferred embodiment of the 
present invention, the buyer 220 vouchers the account 
payable (AP) in its ERP system. The voucher must include 
the payment aging of the individual payment for the par- 
ticular shipment in question. 

In an additional embodiment of the present invention, the 
financial institution 230 itself performs the back office 
operation of vouchering the accounts payable for the client 
220. In this embodiment, the financial institution 230 has 
access to the Purchase Order data and the systems used by 
the client 220 normally used to verify the acceptance of the 
goods (e.g., reports detailing the physical inspection, 
quantity, quality ... of the received goods). In this 
embodiment, the agreement between the client 220 and the 
financial institution must carefully delineate the rules gov- 
erning the process which the financial institution 230 must 25 
follow in accepting the goods. This is critical, because, as 
described below, the acceptance of the goods is the trigger 
for the financial institution to calculate the financing appli- 
cable to the goods and for the forwarding of payment to the 
supplier. 

Returning to the normal AP financing processing, once the 
verified and vouchered AP has been updated in the client's 
220 ERP system, the bank 230 is able to log onto the client's 
220 intra/internet server and extract 260 a file containing the 
daily AP vouchers. In processing the AP vouchers, the 
financial institution 230 first discards vouchered AP's that 
do not match established vendor profiles (i.e., vendor for 
whom supply chain financing has not been set up). The bank 
230 then maps vouchered AP's against the vendor profile 
associated with the vendor 210 which shipped the goods 
reflected by the vouchered AP. Using the vendor profile, the 
financial institution 230 calculates the advance rate appli- 
cable to financing of the particular transaction. The bank 230 
then performs a discount to yield calculation with respect to 
the value date to maturity based on the advance rate data. 
This calculation yields the net proceeds which the bank 230 
will pay to the supplier 210, The bank 230 then calculates a 
payment fee (if any), creates an electronic payment file for 
the net proceeds less payment fee (if any), and sends the 
payment file to the bank's 230 payment system. 

Once the payment file has been created, the bank 230 
sends 270 a payment notice to the buyer 220. The payment 
notice includes the client's 220 reference data (typically the 
PO number). Upon receipt of the payment notice, the buyer 
220 confirms the payment(s) and maturities. In the event 55 
there is a discrepancy between the client's 220 AP/ERP 
system and the bank's 230 payment notice, manual resolu- 
tion of difference is required. Upon approval of the payment 
notice and/or resolution of any discrepancies, the bank 230 



To close the financing loop, on maturity (the agreeing 
date), the client 220 remits 290 the gross proceeds to bank, 
which settles the transaction. 

The AP Financing described above in connection with 
FIG. 2 can work well to improve a buyer's 220 SVA by 
carefully matching the interest cost savings generated to 
create additional days payable outstanding for the buyer 
220. On the other hand, it can be used more aggressively, as 
an incentive or quid pro quo for a supplier 210 to accept 
lower sales prices to its customer/buyer 220. The power of 
this relatively simple structure can be seen in FIG. 3. 

The chart depicted in FIG. 3 shows the number of 
additional days outstanding (and their dollar value at the 
current LIBOR rate) based on the number of basis points (a 
basis point is 1/100 of 1%) difference between the buyer's 
220 and the seller's 210 cost of funds. LIBOR is the London 
Interbank Offer Rate, the most widely used rate for funding 
bank loans to large corporations which is currently about 
5.625%. As an example of the use of the chart depicted in 
FIG. 3, if the buyer's 220 cost of funds is 200 basis points 
less than the seller's 210, and the current payment terms are 
60 days, then through the AP structure of the present 
invention, the buyer 220 could receive an additional 21.8 
days of terms from the seller 210 at no additional receivable 
carrying cost to the seller 210. 

The example of AP Financing given above has broad 
applications. By neutralizing the impact of working capital 
cost across the supply chain, it can encourage experimen- 
tation with various JIT initiatives. The example above shows 
how SCF of the present invention can help trading partners 
create more flexible payment arrangements to meet SVA 
goals. Other SCF structures can help managers optimize the 
physical location of materials without imposing a financing 
35 penalty on one partner. Other structures can facilitate the 
funding of overseas partners facing dramatically higher 
funding costs. 

One step in the process of the present invention briefly 
described above is evaluating whether the process will be 
financially beneficial. The first step in evaluating whether or 
not SCF would provide any benefit to a particular supply 
chain is to do a quick assessment of the net trade cycle of 
each individual company within the supply chain in order to 
determine the dollar value of the potential saving. A simple 
example of a Trade Cycle Map is shown in FIG. 4. In this 
case, the supply chain being mapped includes a primary 
supplier and a single customer, and takes into account the 
supplier's supplier and the customer's customer, the retail 
end-user. 

The Trade Cycle Map shows the assets attributed to the 
supply chain for each participant — inventory and accounts 
receivable. The payable period is the accounts receivable 
period of the supplier. The chart also shows the percentage 
of the Wholesale Value Chain, which is used as a factor in 
order to calculate the potential savings of SCF. The chart can 
be used to derive the net trade cycle of each participant and, 
more importantly, the supply chain as a whole. 

In this example, the Net Trade Cycle of the defined supply 
chain is 130 days — the time from when "Supplier" pays 
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pays 280 the supplier 210. Alternatively, the bank 230 can 60 "Supplier's Supplier" to the time when "Co." is paid by 



pay the supplier 210 simultaneously with its notification to 
the buyer 220. In this embodiment, the above described 
agreement between the buyer 220 and the bank 230 governs 
any dispute as to discrepancies with respect to the payment 
made by the bank 230 to the supplier 210. In a preferred 
embodiment, the payment 280 to the supplier 210 is accom- 
plished via Electronic Funds Transfer (EFT). 



65 



"Customer". Another way to express this is that the supply 
chain "turns" 2.8 times per year. It is observed that in this 
example "Supplier" bears the greatest burden of financing 
this particular supply chain, 90 of the 130 days or about 
70%, whereas "Co." pays about 30% and "Customer" has no 
direct finance cost, having matched the timing of its receiv- 
able with the payment of "Co's" invoice. 
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The mismatched payment terms in this example are 
intended to portray the typical historical relationships 
between buyer and seller over time, and the relative power 
one has over the other. The challenge foremost to corporate 
treasurers is to ensure that a company's business mix reflects 
an overall balance of trading terms so that overall, payables 
fund much of inventory and some receivables, if possible. 
However, trade cycles do not get a great deal of attention at 
the supply chain level, especially if they are being managed 
well overall at the corporate of division level. 

As an illustration of the benefits of the present invention, 
the following assigns credit costs to each of the players in 
the example depicted in FIG. 4. Assume "Supplier", who is 
financing 90 out of the 130 net trade cycle days, is a Korean 
manufacturer. "Co." is a large middle market manufacturer 
and distribution company. And further assume that "Cus- 
tomer" is a leading consumer electronics retailer with a top 
credit rating. The marginal funding costs of each of these 
entities is as depicted in Table 1. 

TABLE 1 



Company 


Marginal Funding Cost 


Korean Manufacturer 


LIBOR + 65% 


("Supplier") 




USA Middle Market Manufacturer 


LIBOR + %S% 


("Co.") 




Strong Retailer ("Customer") 


LIBOR + 0% 



The potential supply chain savings can be derived from 
the following Supply Chain Financing Formula: 



ft 

i=i 



Where V is the dollar amount of annual wholesale value 
chain; n is number of participants, P is the percentage of 
annual value chain contributed by each participant; d is 
number of days each participant finances the value chain; t 
is net trade cycle of supply chain, A is the LIBOR spread of 
each participant; and D is the LIBOR spread of lowest 
funding cost supply chain participant. 

If $100 million wholesale value is assigned to the 
example above, the total potential supply chain finance cost 
savings in this example is therefore $2,525,000 (2.5%). It is 
this amount that would be shared among the supply chain 
participants and the investors, according to the performance 
risks inherent in the transaction and how the financing would 
be structured. 

FIG. 5 illustrates an alternative embodiment of the present 
invention. Although this embodiment also uses the Account 
Payable as the trigger for the financing, in contrast to the 
previous embodiment, where the buyer assumed full risk, in 
the present embodiment the seller is advanced a payment 
prior to shipment of the goods and the buyer has recourse 
against the supplier for at least part of the advance. This 
embodiment is known as Vendor Financing. 

The evaluation process for Vendor Financing is the same 
as described above with respect to the AP Financing 
depicted in FIG. 2. The three entities depicted in FIG. 5, the 
buyer 220, the supplier 210 and the financial institution 230 
are the same as those depicted in FIG. 2. The set-up process 
for Vendor Financing is slightly different from that described 
above. In determining the Advance rates which are appli- 
cable to the participating suppliers 210, the bank 230 will 
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determine two Advance Rates, one for pre -shipment 
advances against Purchase Orders and one for post -shipment 
advances against Accounts Payable. Furthermore, the bank 
230 will determine the total amount of final credit that may 
be taken by the buyer 220 following shipment, against any 
single payment and a maximum dollar limitation for same. 

As with the AP financing described above, an agreement 
between the buyer 220 and the bank 230 must be reached. 
Again, a key provision for a Vendor Financing agreement 
includes establishing the rules by which the financial insti- 
tution can identify when the client 220 has accepted good 
from the supplier 210, as previously described above. Other 
provisions for a Vendor Financing agreement include: the 
amount and form of recourse to buyer 220 for pre-shipment 
advances; an agreement by the client 220 to pay the financial 
institution upon maturity of the underlying item; procedures 
for the resolution of post acceptance disputes (usually in the 
form of a put to the client of the underlying asset); proce- 
dures for the resolution of pre-acceptance disputes; and 
establishment of reliance on the selected method of com- 
munication (this will typically place no liability on the part 
of financial advisor 230 to advance funds in the event of 
communications/software failure). 

In addition to an agreement between the bank 230 and the 
buyer 220 for Vendor Financing, an agreement between the 
bank 230 and suppliers) 210 is also required. The key 
provisions of this agreement between the bank 230 and 
suppliers) 210 include: secondary recourse provisions, if 
any; procedures for the resolution of pre-acceptance dis- 
putes; and hold harmless clauses in which no liability on the 
part of financial advisor 230 to advance funds in the event 
of communication/software failure. 

As in the AP financing, the final technical step is for the 
financial institution to obtain extra/intra/internet dial-up and 
logon access to the ERP system of the buyer 220. 

The actual financing process for Vendor financing will be 
described in connection with FIG. 5. As with AP financing, 
the process starts by the client 220 manually or via electronic 
link sending 510 a request for goods (e.g., a Purchase Order) 
to the vendor 210. The fact of the transmission and the 
contents of the PO are updated in client's ERP system. In 
parallel with the transmission of the PO to the vendor 210, 
the PO is also sent 515 to the financial institution 230. This 
transmission can either be initiated by the buyer 220 or by 
prearranged and/or regularly scheduled download by the 
bank 230. In the preferred embodiment, this download 
occurs via the electronic interface between the bank 230 and 
the buyer 220. 

At the bank 230, the PO data are matched against Vendor 
Profile. The bank 230 calculates a pre-shipment advance rate 
applicable to the transaction represented by the PO and runs 
a discount to yield calculation on value date to estimated 
settlement date based on the above calculated advance rate. 
This calculation determines the advance proceeds which will 
be forwarded to the supplier 210. The financial institution 
then calculates payment fee, if any, and creates an electronic 
payment file for the advanced proceeds less the payment fee, 
if any. 

At this point, the advanced proceeds are transferred 520 
from the bank 230 to the supplier 210, preferably through 
Electronic Funds Transfer. The bank 230, in conjunction 
with the funds transfer, also sends 525 a payment notifica- 
tion to the client 220 which references the client's reference 
data (typically the PO number). The payment notice con- 
firms the payments) to the supplier 210 and also confirms 
the estimated maturities. This process is slighdy different 
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from the process described above with respect to the AP 
financing in that the funds were sent 520 prior to notifying 
525 the buyer 220. Either procedure is acceptable and can be 
used in either process. 

In step 530 the vendor 210 ships the merchandise to the 
buyer 220. Acknowledgement of merchandise shipment 
(transfer of title) can be made by one of three ways: via the 
client's 220 receipt of the goods (as evidenced by a dock or 
warehouse receipt); via an invoice transmitted 540 by elec- 
tronic means from the vendor 210 to the buyer 220; or via 
an invoice in hardcopy form from the vendor 210 to the 
buyer 230. 

Regardless of the method by which the shipment 530 of 
the goods is acknowledged, the buyer 220 updates its ERP 
system to reflect the receipt of the goods. The buyer 220 then 
matches the delivery/invoice data to the PO data correspond- 
ing to the delivery. If the acknowledgement data does not 
meet the buyer's 220 payment rules, then adjudication is 
required between the client 220 and the vendor 210 in order 
to determine the value of shipped goods which are ineligible 
for additional financing. The bank 230 may invoke the 
recourse provisions of the agreement and have the underly- 
ing assets removed from funding. 

If the acknowledgement data meets the client's 220 
payment rules, then the buyer 220 may deduct any credits 
due the buyer 220 up to the agreed upon percentage and 
within the total dollar limitation as set forth in the agree- 
ments. Once the validity of the invoice data has been 
established, the buyer 220 indicates its acceptance of the 
goods in accordance the manner established by the rules 
between the buyer 220 and the financial institution 230. 
Again, as described above with respect to the AP financing 
embodiment, in the preferred embodiment of the present 
invention, the buyer 220 vouchers the account payable (AP) 
in its ERP system. The voucher must include the payment 
aging of the individual payment for the particular shipment 
in question. 

Once the verified and vouchered AP has been updated in 
the client's 220 ERP system, the bank 230 is able to log onto 
the client's 220 intra/internet server and extract 560 a file 
containing the daily AP vouchers. In processing the AP 
vouchers, the financial institution 230 first discards 
vouchered AP's that do not match established vendor pro- 
files (i.e., vendor for whom supply chain financing has not 
been set up). The bank 230 then maps vouchered AP's 
against the vendor profile associated with the vendor 210 
which shipped the goods reflected by the vouchered AP. 
Using the vendor profile, the financial institution 230 cal- 
culates the advance rate applicable to financing of the 
particular transaction. 

In contrast to the AP financing previously described, the 
bank 230 then adjusts the discount to yield substituting a 
final correct settlement date (when the first advance was 
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the client's 220 reference data. Upon receipt of the payment 
notice, the buyer 220 confirms the payments) and maturi- 
ties. In the event there is a discrepancy between the client's 
220 AP/ERP system and the bank's 230 payment notice, 
manual resolution of difference is required. 

To close the Vendor Financing loop, on maturity (the 
ageing date), the client 220 remits 570 the gross proceeds to 
bank, which settles the transaction. 

Although the present invention has been described in 
relation to particular embodiments thereof, many other 
variations and modifications and other uses will become 
apparent to those skilled in the art. It is preferred, therefore, 
that the present invention be limited not by the specific 
disclosure herein, but only the gist and scope of the disclo- 
sure. 

What is claimed: 

1. A method for financing, through a third party, a supply 
of goods from a supply chain to a buyer, the supply chain 
consisting of a number of participants, wherein the buyer 
and each participant in the supply chain have a cost of 
financing, the method comprising the steps of: 

identifying a first participant that has a cost of financing 
that is the greatest above the buyer's cost of financing; 

establishing rules between the buyer and the third party 
including establishing, in a first rule, a manner in which 
the third party can identify acceptance data represent- 
ing acceptance of goods by the buyer; 

the third party identifying acceptance data related to 
goods accepted by the buyer; 

calculating the financing for the goods in response to the 
identified acceptance data and in response to the estab- 
lished rules; 

forwarding payment for the goods from the third party to 
the first participant prior to a time the payment for the 
goods would normally be payable; and 

at maturity of the financing, settling the financing between 
the buyer and the third party. 

2. The method as set forth in claim 1, wherein the 
calculating step comprises the steps of: 

determining an advance rate; 

performing a discount to yield calculation with respect to 
a value date to maturity in response to the advance rate; 
and 

determining net proceeds in response to the discount to 
yield calculation, wherein the net proceeds are the 
payment forwarded to the one participant. 

3. The method as set forth in claim 1, further comprising 
the step of establishing a supplier profile containing advance 
rates and payment terms applicable to the first participant. 

4. The method as set forth in claim 1, wherein the first rule 
includes an agreement by the buyer to repay payments made 
by the third party to the first participant in reliance on 



made, the final settlement date was not fixed) The final 55 proper iy identified acceptance data 



settlement date is the date represented by the client's ageing 
or other rule based date. The financial institution 230 then 
calculates the discount to yield on the remaining unfunded 
balance of the shipment value in order to determine the net 
proceeds which the bank 230 will pay to the supplier 210. go 
The bank 230 then calculates a payment fee (if any), creates 
an electronic payment file for the net proceeds less payment 
fee (if any), and sends 550 the payment via EFT to the 
supplier 210. 

Once the net proceed payment has been made 550 to the 65 
supplier 210, the bank 230 sends 560 a further payment 
notice to the buyer 220. The payment notice again includes 



5. The method as set forth in claim 1, wherein the 
acceptance data is generated by the financial institution by 
performing an account payable vouchering process for the 
buyer. 

6. The method as set forth in claim 1, further comprising 
the steps of: 

generating a request for the goods by the buyer; 

transmitting the request to the supply chain; and 

shipping the goods from the supply chain to the buyer; 

wherein the invoice data is generated by the supply chain 
and transmitted to the buyer, the invoice data is cap- 
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tured in a buyer's database, and wherein the invoice 
data is received by the third party from the buyer's 
database. 

7. A method for financing, through a third party, a supply 
of goods from a supply chain to a buyer, the method 
comprising the steps of: 
establishing rules between the buyer and the third party 
including establishing, in a first rule, a manner in which 
the third party can identify acceptance data represent- 
ing acceptance of goods by the buyer; 

the third party identifying acceptance data related to 

goods accepted by the buyer; 
evaluating the savings to be obtained by the financing, 

wherein the evaluating step is accomplished using the 

formula: 

n 

i=i 



where V is the dollar amount of annual wholesale value 
of the supply chain; n is the number of participants in 
the supply chain, P is the percentage of annual whole- 
sale value of the supply chain contributed by each 
participant; d is number of days each participant 
finances the wholesale value of the supply chain; t is net 
trade cycle of the supply chain, A is the LIBOR spread 
of each participant; and D is the LIBOR spread of the 
lowest funding cost supply chain participant; 

calculating the financing for the goods in response to the 
identified acceptance data and in response to the estab- 
lished rules; 

forwarding payment for the goods from the third party to 
one of the participants in the supply chain prior to a 
time the payment for the goods would normally be 
payable; and 

at maturity of the financing, settling the financing between 
the buyer and the third party. 

8. A method for financing, through a third party, a supply 
of goods from a supply chain to a buyer, the supply chain 
consisting of a number of participants, the method compris- 
ing the steps of: 

generating request data representing a request for the 
goods; 

receiving the request data by at least one of the partici- 
pants in the supply chain and the third party; 

calculating financing for the requested goods in response 
to the received request data; 

forwarding a first payment for the goods from the third 
party to the at least one participant; 

shipping the goods; 

generating invoice data representing the shipment of the 
goods; 

receiving invoice data by the third party representing the 

shipment of goods; 
calculating a remaining payment, if any, with respect to 

the shipped goods in response to the received invoice 

data and in response to the first payment; 
forwarding the remaining payment, if any, from the third 

party to the at least one participant; and 
at maturity of the financing, settling the financing between 

the buyer and the third party. 

9. The method as set forth in claim 8, wherein the 
financing is calculated using an advance rate and wherein 
the remaining payment is calculated at a final rate. 
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10. The method as set forth in claim 9, wherein advance 
rate and the final rate are different. 

U. The method as set forth in claim 8, further comprising 
the steps of: 

prior to calculating the financing for the goods, evaluating 
the savings to be obtained by the financing. 

12. The method as set forth in claim 11, further compris- 
ing the step of performing the steps of claim 12 with respect 
to the participant in the supply chain in which the evaluated 
savings obtained by the financing is the greatest. 

13. The method as set forth in claim 8, wherein the step 
of calculating the financing comprises the steps of: 

determining an advance rate; 

performing a discount to yield calculation with respect to 
a value date to maturity in response to the advance rate; 
and 

determining net proceeds in response to the discount to 
yield calculation, wherein the net proceeds are the first 
payment forwarded to the at least one participant. 

14. The method as set forth in claim 13, wherein the value 
date to maturity is an estimated value date to maturity. 

15. The method as set forth in claim 8, further comprising 
the step of: 

notifying the buyer of the first payment to the at least one 
participant. 

16. The method as set forth in claim 8, further comprising 
the steps of: 

establishing a supplier profile containing a pre-shipment 
advance rate applicable to financing prior to shipment 
of the goods and a post-shipment advance rate appli- 
cable to financing after shipment of the goods. 

17. The method as set forth in claim 16, wherein the step 
of determining the advance rate comprises retrieving the 
advance rate from the supplier profile. 

18. The method as set forth in claim 8, further comprising 
the steps of: 

determining an amount of final financing available to 
buyer following shipment of the goods; and 

determining a maximum dollar limit of the final financing. 

19. The method as set forth in claim 8, wherein the third 
party is a bank. 

20. The method as set forth in claim 8, wherein the buyer 
has recourse against the at least one participant at least with 
respect to the first payment. 

21. The method as set forth in claim 8, wherein at least the 
first payment is made to the at least one participant by an 
electronic medium. 

22. The method as set forth in claim 8, wherein the request 
data is a purchase order. 

23. The method as set forth in claim 8, wherein the 
invoice data is generated in response to a receipt of the 
goods by the buyer. 

24. A method for financing, through a third party, a supply 
of goods from a supply chain to a buyer, the supply chain 
consisting of a number of participants, wherein the buyer 
and each participant in the supply chain has a cost of 
financing, the method comprising the steps of: 

generating request data representing a request for the 
goods; 

receiving the request data by at least one of the partici- 
pants in the supply chain and the third party; 

evaluating the savings to be obtained by the financing, 
wherein the evaluating step is accomplished using the 
formula: 
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where V is the dollar amount of annual wholesale value 
of the supply chain; n is the number of participants in 
the supply chain, P is the percentage of annual whole- 
sale value of the supply chain contributed by each 
participant; d is number of days each participant 10 
finances the wholesale value of the supply chain; t is net 
trade cycle of the supply chain, A is the LIBOR spread 
of each participant; and D is the LIBOR spread of the 
lowest funding cost supply chain participants; 

15 

calculating financing for the requested goods in response 
to the received request data; 



14 

forwarding a first payment for the goods from the third 
party to the first participant; 

shipping the goods; 

generating invoice data representing the shipment of the 
goods; 

receiving invoice data by the third party representing the 

shipment of goods; 
calculating a remaining payment if any, with respect to the 

shipped goods in response to the received invoice data 

and in response to the first payment; 
forwarding the remaining payment, if any, from the third 

party to the first participant; and 
at maturity of the financing, setding the financing between 

the buyer and the third party. 

***** 
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METHODS AND INVESTMENT 
INSTRUMENTS FOR PERFORMING TAX- 
DEFERRED REAL ESTATE EXCHANGES 

FIELD OF THE INVENTION 

The present invention relates generally to methods and 
investment instruments for performing tax-deferred real 
estate transactions, and more particularly to methods and 
instruments for performing tax-deferred exchanges of 
investment real estate under 26 U.S.C. §1031. 

BACKGROUND OF THE INVENTION 

As the population of America ages, the investment con- 
cerns of Americans are changing. Mature investors desire 15 
investments that provide a safe, steady income stream. Such 
investors also generally desire liquidity, so that their invest- 
ment interests can easily be sold or rearranged. Additionally, 
investors generally do not want to actively manage their 
investments. 

Mature investors also may have numerous concerns 
related to inheritance. For example, most mature investors 
would like their investments to be divisible, so that they may 
be easily divided among heirs. Additionally, these investors 
may want their estates to be able to sell part of their 
investment holdings to pay estate taxes. 

Investment real estate has difficulties meeting many of 
these desires. Generally, small to mid-sized real estate 
holdings require active management to return a steady 
income. Furthermore, if an investor divides the title to a 
small real estate holding, such as a store, or a single building, 
the pieces generally have less value than the whole and are 
difficult, expensive and time-consuming to sell. Many of the 
foregoing concerns affect investors of all age groups, par- 
ticularly in view of the challenging lifestyles of most mod- 
em American workers and professionals. 

Despite the foregoing difficulties, however, a large 
amount of money is currently invested in real estate that is 
either income-producing or held for investment. In 1996, for 
example, the total value of commercial real estate in the 
United States was estimated at approximately four trillion 
dollars. Much of this real estate (approximately $2.75 tril- 
lion in 1996) was privately owned and held by individuals 
and corporations. A sizable fraction of these holdings are 45 estate investment trust (a "REIT"). A REIT is a company that 
owned by small to mid-sized real estate investors (i.e., those buys, sells, manages, and develops real estate or real estate 
having holdings between $500,000 and $10 million). mortgages on behalf of its investors. Shares in a REIT may 

Such small to mid-sized real estate owners can sell their be purchased, or (for some REITS) acquired indirectly in 
real estate and put their earnings into investments such as exchange for property, as described below. These shares are 
high grade bonds or bond funds, which provide the kind of 50 often publicly traded on major exchanges, and have char- 
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that are equal to or greater than the value and debt of 
property being sold (the "relinquished property"). 

Thus, if the relinquished property was sold for $450,000, 
and was subject to a $100,000 mortgage, the replacement 
property must be purchased for at least $450,000, and must 
be subject to at least $100,000 in debt. If the value or debt 
of the replacement property is less than that of the relin- 
quished property, taxes are payable on the difference, known 
as "boot". 

IRC § 1031 also imposes certain time limits for comple- 
tion of the transaction. Once the relinquished property has 
changed ownership, the owner of the exchanged property 
(the "exchanger") has 45 days to identify replacement 
property choosing either the three-property or the 200% rule, 
and a total of 180 days to close on the replacement proper- 
ties. If these time limits are not met, the transaction is not 
deemed to be an "exchange/' and gains from the sale are 
subject to taxation. Additionally, the exchanger cannot exer- 
cise control, either direct or indirect, over the proceeds of the 
sale of the first property. For this reason, IRC §1031 
exchanges generally are handled by a third party, a so-called 
"qualified intermediary," who sells the relinquished property 
on behalf of the exchanger, holds the proceeds of the sale, 
acquires the replacement property that has been designated 
by the exchanger, and transfers title to the replacement 
property to the exchanger. 

IRC §1031 exchanges help in meeting the concerns of 
many investors by permitting a tax-deferred exchange. For 
most owners of high-maintenance investment or commercial 
real estate, or investment real estate without a safe, steady 
income stream, however, it is difficult to locate an acceptable 
replacement property requiring less active management and 
that produces a more steady income stream. Also, because 
the investment is still in real estate, other concerns of 
investors, such as liquidity and divisibility are not addressed 
by the availability of IRC §1031 exchanges. Furthermore, 
many attempted IRC §1031 exchanges fail, with devastating 
tax consequences, due to difficulties in identifying and 
closing on suitable replacement properties within the time 
limits imposed by the statute. 

Numerous attempts have been made to provide real estate 
investments that are transferable, have a steady income 
stream, require low management effort, and are divisible. 
One way of gaining these benefits is by investing in a real 



liquidity, and relatively safe and steady income that many 
investors desire. Unfortunately, selling investment real 
estate or commercial real estate that has appreciated in value 
may result in severe tax consequences. For example, a 
property that was originally purchased many years ago for 55 
$50,000, and sold for $450,000, has a taxable gain of 
$400,000. Under the current tax code, as much as 28% of 
this gain (or $112,000), is payable as federal tax. 

Title 26, Section 1031 of the Internal Revenue Code 
(hereinafter "IRC § 1031") permits deferral of the taxes on 60 
investment real estate by reinvesting in other investment real 
estate, subject to several conditions. Thus, for example, the 
owner of a small store could use a "1031 exchange" to defer 
taxes when he or she sells the store and reinvests the 
proceeds in an apartment building. To receive all of the 65 
benefits from an IRC § 1031 exchange, the new property 
(the "replacement property") must have both value and debt 



acteristics similar to the characteristics of shares in any other 
company. For example, the shares are easy to liquidate, and 
often provide a reasonably steady stream of income through 
dividends. 

A real estate investor goes through a two-step process if 
he or she seeks to use a REIT to take advantage of a 
tax-exempt transaction. First, the investor contributes the 
real estate property to a partnership owned by the REIT. 
Next, at such time as the investor elects to liquidate his or 
her interest, he or she exchanges the partnership interest for 
REIT shares. The second exchange is a taxable exchange 
and the investor may not utilize IRC §1031 to acquire other 
real estate in a tax exempt transaction. Once the investor 
completes the first step the only option the investor has is to 
acquire REIT shares in a taxable transaction. 

Basically, shares in a REIT are simply shares in a 
company — not a deeded ownership interest in specific com- 
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mercial or investment real estate. Thus, individual share- 
holders in a REIT may not be able to exert much control over 
the size or investment quality of the holdings of the REIT 
over a long term. Also, the market value of the REIT shares 
may fluctuate differently than the market value of the assets 
owned by the REIT In addition, an IRC §1031 exchange 
cannot be used to defer the taxes on an exchange of 
investment property for shares in a REIT. REITs therefore 
do not provide a way to convert an interest in real estate into 
an investment with more desirable characteristics without 
incurring significant market risk and tax consequences. 

Another way of spreading the risk and management 
burden of a real estate investment is to join a group of 
investors to purchase real estate as tenants-in-common. In 
arrangements of this sort, each of the tenants-in-common 
typically receives an undivided part interest in the real estate 
that is the subject of the transaction, in proportion to the 
amount of his or her investment. The tenants-in-common 
also enter into an agreement providing for exercise of joint 
control over the property, and for sharing the maintenance 
and management costs. 

While the foregoing approach may provide a steady 
income stream from a real estate investment with certain 
favorable attributes, such arrangements have several disad- 
vantages. First, it may not be easy to liquidate an undivided 
part interest in real estate due to the specific nature of the 
underlying assets. Additionally, depending on the number of 
investors involved and the nature of the agreement under 
which control is exercised over the property, such an 
arrangement may be deemed by the Internal Revenue Ser- 
vice to constitute a partnership. Since IRC §1031 specifi- 
cally excludes exchanges of interests in partnerships, it is not 
possible to do a tax deferred exchange into this type of 
arrangement. 

In view of the foregoing, it would be desirable to provide 
methods of investing in real estate that provide safety, a 
steady income stream, divisibility, ready liquidity, and no 
involvement in management of the property. 

It would further be desirable to provide an investment 
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may be readily alienated, and that provides a steady and 
relatively low risk return. 

It is a still further object of the present invention to 
provide a system for implementing methods that enable 
investors to realize substantial tax-deferred benefits in accor- 
dance with IRC §1031. 

These and other objects of the present invention are 
achieved by creating a new type of investment instrument, 
a "deedshare," that represents both a tenant-in-common 
interest in real estate, and provides the divisibility and 
liquidity of a traditional security, such as a bond. Deedshares 
created in accordance with the principles of the present 
invention preferably are available in predetermined 
denominations, provide a guaranteed steady income stream, 
are readily transferable, readily alienated, and are suitable 
for identification as replacement property under IRC §1031. 
The deedshares may be encumbered by a mortgage, as 
required by the particular needs of an individual investor, so 
as to comply with the debt provisions of IRC §1031. 
Because deedshares are a direct interest in investment real 
estate, and the tenant-in-common owners of the real estate 
do riot exercise significant control, and thus are not deemed 
partners, investors may use IRC §1031 to perform tax- 
deferred exchanges. 

In accordance with the methods of the present invention, 
a series of steps are involved in creating and managing this 
new type of real estate investment. First, real property 
having a preselected total value is purchased and aggregated, 
and may consist of a number of commercial real estate 
parcels. The aggregated properties are then made subject to 
at least one master agreement. Title to the property is then 
divided into tenant- in-common deeds of at least one pre- 
determined denomination. The master agreements include a 
provision by which the tenant-in-common deeds may be 
"re aggregated" after a specified interval, so that the property 
may be disposed of. The tenant-in-common deeds, subject to 
master agreements configured in accordance with the meth- 
ods of the present invention, are referred to herein as 



instrument and methods for exchanging investment or com- 40 "deedshares/' 

mercial real estate that provide safety, a steady income In a preferred embodiment, the master agreements include 

stream, divisibility, ready liquidity, and no involvement in * master lease, under which the property is leased to a master 

management of the property, and that meet the requirements tenant, who manages the property. During the term of the 

of IRC §1031, thereby enabling a tax-deferred exchange. master lease, the deedshare holders receive a steady, guar- 

It still further would be desirable to provide an investment 45 anteed income stream from the master tenant, similar to the 



that permits substantial tax-deferral benefits, that may be 
readily alienated, and that provides a steady and relatively 
low risk return. 

It even further would be desirable to provide a system for 
implementing methods that enable investors to realize sub- 
stantial tax -deferred benefits in accordance with IRC §1031. 

SUMMARY OF THE INVENTION 
It is an object of the present invention to provide methods 



income one might expect from a high grade bond, e.g., a 
bond having an AA rating or better. This guaranteed steady 
income stream also provides a high degree of liquidity. The 
deedshare holders also obtain favorable tax treatment by 
5 q being allocated their proportionate share of depreciation so 
long as they own a deedshare. 

At the end of the interval specified in the master lease, the 
deedshares are subject to a put/call arrangement, whereby 
the individual owners of deedshares have a right and an 



and an investment instrument for investing in real estate that 55 obligation to sell their deedshares to the master tenant or 
provide safety, a steady income stream, divisibility, ready some third-party, receiving fair market value for their deed- 
liquidity, and no involvement in management of the prop- shares. This serves to reaggregate title to the property under 
erty. the master tenant. The former deedshare holders may, sub- 

It is another object of this invention to provide investment ject to IRC §1031 guidelines and prior to the re aggregation 
instruments and methods for exchanging investment or eo °f me property, exchange the deedshares for deedshares 



commercial real estate for an interest in investment in 
specific real estate that provide safety, a steady income 
stream, divisibility, ready liquidity, and no involvement in 
management of the property, and that meet the requirements 
of IRC §1031. 

It is a further object of the present invention to provide an 
investment that permits substantial tax-deferral benefits, that 



having a later maturity date, or for other investment real 
estate, through another tax-deferred IRC §1031 exchange. 

A system of implementing the deedshares and methods of 
the present invention is also provided for use with a com- 
65 puter system, which enable automated tracking of various 
items of information relating to the real estate portfolio, 
master agreement, and investors. 
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not be viewed as an exchange of property, and the proceeds 
of the sale of the relinquished property may be taxable. It 
should also be noted that tax-deferred exchanges under IRC 
§1031 also require that the exchanger intend to hold the 
replacement property for productive use in a trade or busi- 
ness or for investment. 

IRC §1031 also sets out certain exceptions. One important 
exception is that interests in a partnership are not subject to 
tax-deferred exchanges. Other exceptions include beneficial 
interests, and property held primarily for sale. 

Problems with identifying and closing on replacement 
properties within the required time limits cause many 
attempted §1031 exchanges to fail, with substantial negative 
tax consequences to the property owner who was attempting 
the exchange. In addition, because §1031 exchanges simply 
trade the relinquished property for the replacement property, 
it is difficult to use a §1031 exchange to acquire an invest- 
ment interest with diversity, divisibility, high liquidity, or 
guaranteed returns. 

To address these difficulties with IRC §1031 exchanges, 
the applicants have developed new methods, and investment 
instruments especially suited for performing real estate 
exchanges. In accordance with the principles of the present 
invention, this new investment instrument provides an 
exchanger with a direct interest (i.e. not a beneficial interest 
or partnership interest) in real estate, so that a tax-deferred 
exchange under IRC §1031 may be used to trade into the 
new investment. The new investment also is easy to identify 
as a replacement property and to close on, so that there are 
no difficulties in completing the transaction within the time 
limits specified in IRC §1031. Additionally, the investment 
created in accordance with the present invention preferably 
provides guaranteed returns, a steady income stream, 
diversity, divisibility, and liquidity. 

Referring now to FIG. 2, the structure and operation of a 
preferred embodiment of the investment methods and 
investment instrument of the present invention are 
described. First, a number of commercial properties are 
identified and acquired to form a real estate portfolio 20, a 
process referred to herein as "aggregation/* Because a large 
number of quality properties are selected for the portfolio, 
the aggregate value of the portfolio may be quite high, e.g., 
several tens of millions of dollars. This in turn makes the 
portfolio an attractive investment opportunity, and enables a 
resale market to be readily established. 

Real estate portfolio 20, illustratively comprising real 
estate having a total value of $100 million, then is subjected 
to a master agreement, described hereinbelow, and divided 
into deedshares 22 having of a single or multiple specified 
denominations. In FIG. 2, each of deedshares 22 illustra- 
tively has a specified denomination of $100,000 per deed 
share, so that the $100 million value of real estate portfolio 
20 is divided into one thousand $100,000 deedshares 22. 
Each of deedshares 22 is a tenant-in-common deed to a 
55 proportional (0.1%) undivided part interest in real estate 
portfolio 20. As an interest in real property, each deedshare 
22 may be subjected to a separate mortgage in whatever 
amount is required to meet the needs of a particular investor, 
thus enabling the transaction to comply with the debt 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects and advantages of the present 
invention will be apparent upon consideration of the fol- 
lowing detailed description, taken in conjunction with the 
accompanying drawings, in which: 

FIG. 1 illustrates a prior art IRC §1031 exchange con- 
ducted through a qualified intermediary; 

FIG. 2 shows the structure of the new real estate invest- 
ment methods and investment instrument of the present 
invention; 

FIG. 3 depicts an illustrative embodiment of an invest- 
ment instrument of the present invention; 

FIGS. 4A-C illustrate steps taken by each party to an IRC 
§1031 exchange performed in accordance with a preferred 
embodiment of the present invention; 

FIG. 5 shows an IRC §1031 exchange used for tax- 
deferred exchange of investment property for "deedshare," 
in accordance with the principles of the present invention; 

FIG. 6 is a flowchart of an IRC §1031 exchange in which 
investment property is exchanged for deedshares; 

FIG. 7 depicts an illustrative computer database structure 
for implementing the methods and investment instrument of 
the present invention; and 

FIG. 8 shows an illustrative computer system and network 
for executing a database application implementing the meth- 
ods and investment instrument of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring to FIG. 1, a previously known tax-deferred 
exchange according to IRC §1031 (Title 26, United States 
Code Section 1031) is described. Exchanger 10, who wishes 
to exchange investment real property A, provides a third 
party, typically qualified intermediary 12, with the deed to 
property A. Qualified intermediary 12 then transfers the 
property to buyer 14 in exchange for money. Once the 
property is transferred to buyer 14, IRC §1031 specifies that 
exchanger 10 has 45 days to designate replacement 
properties, and 180 days to close on any replacement prop- 
erties for the transaction to be considered an "exchange/* 
Exchanger 10 designates replacement investment real prop- 
erty B, owned by owner 16. Qualified intermediary 12 then 
acquires replacement property B from owner 16 and trans- 
fers replacement property B to exchanger 10 and money to 
owner 16. Exchanger 10 must obtain a mortgage replace- 
ment on property B in an amount at least equal to the amount 
of any mortgages on relinquished property A. 

In designating replacement properties under IRC §1031, 
exchanger 10 may identify up to 3 potential properties to 
serve as replacements. More than three replacement prop- 
erties may be identified, as long as the aggregate value of all 
of the designated properties adds up to no more than twice 
the value of the relinquished property. 

IRC §1031 also requires that when the exchange is 
complete, the value and debt of the replacement property 
must both be greater than or equal to the value and debt of 
the relinquished property. If the replacement property has a 60 provisions of IRC §1031. In accordance with the principles 

of the present invention, and to provide desirable character- 
istics such as liquidity and guaranteed income, each of 
deedshares 22 is created subject to master agreement 24, 
which preferably includes a master lease, as described 
65 hereinafter. 

Master agreement 24 comprises an agreement that ensures 
that all of deedshares 22 can be reaggregated after a speci- 
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lower value, or is subject to a smaller mortgage than the 
relinquished property, the boot is taxable. This rule ensures 
that taxes are paid on any money that is taken out of the 
investment real estate during the exchange. 

Qualified intermediary 12 is used to perform the 
exchange, because if exchanger 10 exercises control over the 
money acquired from buyer 14, the entire transaction may 



02/24/2003, EAST version: 1.03.0002 



US 6,292,788 Bl 



8 



fied interval, e.g., 10 years, so that real estate portfolio 10 
may be disposed of, and the proceeds distributed to the 
holders of deedshares 22. This mechanism provides a way to 
get invested money back out of real estate portfolio 20 
without requiring that the holders of deedshares 22 exercise 5 
control over their individual ownership interests, thereby 
avoiding the attributes of a partnership. 

In a preferred embodiment, the agreement to reaggregate 
the property interests of deedshares 22 may be achieved by 
building a put/call mechanism in the deedshare, whereby 10 
each of the individual owners of deedshares 22 has a right 
and an obligation to sell deedshares 22 to a specified buyer 
(e.g., the entity holding the master lease) at fair market 
value. Other types of agreements also may be used for this 
purpose. For example, master agreement 24 may include an 15 
exclusive sales provision, giving a specified real estate 
broker the exclusive right to sell real estate portfolio 20 after 
the specified time. Generally, any agreement whereby own- 
ership of deedshares 22 is conditioned upon an agreement to 
sell the deedshares, at a specified time (or maturity date), or 20 
under specified conditions, is expected to accomplish the 
goal of reaggregating the tenant-in-common interests repre- 
sented by deedshares 22 into a unified title in real estate 
portfolio 20. 

Master agreement 24 preferably comprises provisions that 25 
prevent holders of deedshares 22 from providing common 
services with respect to real estate portfolio 20, from enter- 
ing into joint venture activities with respect to real estate 
portfolio 20 with fellow owners of deedshares 22, from 
establishing a common trade name in relation to their 30 
holdings of deedshares 22, and from commingling or estab- 
lishing joint financial arrangements with respect to real 
estate portfolio 20 with other owners of deedshares 22. 
These provisions are intended to prevent owners of deed- 
shares 22 from acquiring the attributes of a partnership, 35 
which might otherwise make deedshares 22 ineligible for 
tax-deferred treatment under IRC §1031. 

For the foregoing reason, master agreement 24 preferably 
also includes no provisions that require joint management 4Q 
activity on the part of owners of deedshares 22. For example, 
the owners of deedshares 22 should not be required (or 
permitted) to vote on the sale of real estate portfolio 20. 

In a preferred embodiment, master agreement 24 com- 
prises a master lease, whereby a master tenant is placed over 45 
the properties in real estate portfolio 20. The master tenant 
agrees to pay rent to the owner of portfolio 20, including the 
individual holders of deedshares 22, over a specified term. 
The master tenant also is given the right to sublease the real 
estate, and is responsible for paying the taxes, upkeep, 50 
maintenance, and insurance on the leased property. 

The credit rating of the master tenant plays a role in 
ensuring that the holders of deedshares 22 receive a guar- 
anteed income stream from the rent paid by the master 
tenant. Preferably, the master tenant is a commercial entity 55 
having at least an AA credit rating or better. Alternatively, a 
master tenant having a credit rating less than AA may be 
employed, in which case the master tenant may be "credit 
enhanced" by making a payment to a third party to guarantee 
any shortfall between the rate of return guaranteed in the ,50 
deedshare and the actual income from the property. 

Applicants believe that by providing a guaranteed income 
stream over a specified term, the investment instrument and 
methods of the present invention will make the investment 
value of deedshares 22 comparable to that of high quality 65 
commercial bonds. Accordingly, it should be possible to 
establish a market in this type of investment instrument, thus 



making deedshares 22 easy to liquidate. It is expected, for 
example, that it should be possible to buy or sell deedshares 
22 in the same manner that bonds or shares of mutual funds 
currently are traded. 

Master agreement 24 also may contain other provisions 
relating to the master tenant. For example, the put/call 
provisions preferably specify the master tenant as the entity 
to which deedshares 22 are sold at the end of the specified 
time. Additionally, it is possible to adjust the profit made by 
the master tenant on this sale by adjusting the term of the 
master lease and the specified time during which deedshares 
22 are held to maturity. 

For example, if the master lease is for a term of 15 years, 
but deedshares 22 call for title to the real estate portfolio to 
be reaggregated after 10 years, then the fair market value of 
real estate portfolio 20 will be influenced by the encum- 
brance of the additional five year term of the lease. 
Accordingly, the master tenant will be able to purchase real 
estate portfolio 20 back from the holders of deedshares 22 at 
a favorable price, thus encouraging the funding of such 
arrangements. 

As will be understood by one skilled in the banking and 
investment arts, the size of real estate portfolio 20 may be 
selected to suit the needs of the prospective pools of inves- 
tors. Additionally, the denominations of deedshares 22 may 
be selected at any suitable value, and real estate portfolio 
may include several classes of deedshares, each class having 
a different predetermined denomination. The terms of master 
agreement 24 also may be varied, depending on the nature 
and growth objectives of real estate portfolio 20 and the 
needs of prospective investors. 

Referring to FIG. 3, an example deedshare is shown. As 
discussed above, deedshare 25 comprises a tenant-in- 
common part interest in the property. Deedshare 25 has 
predetermined denomination 26 ($100,000 in this case), that 
determines the share of an overall real estate portfolio that 
is represented by deedshare 25. Deedshare 25 also includes 
master agreement 27, that includes provision 27a for 
reaggregating title to the property in the real estate portfolio 
after a specified interval. In a preferred embodiment, this is 
accomplished through use of a put/call provision, as 
explained above. 

In a preferred embodiment of deedshare 25, master agree- 
ment 27 also comprises provision 27b, which prevents 
holders of the deedshares from exercising control over the 
property interest represented by deedshare 25, so that the 
deedshare holders may not be deemed to be a partnership, as 
explained above. A preferred embodiment of deedshare 25 is 
also encumbered by master lease 28, whereby the real estate 
interest represented by deedshare 25 is leased for a specified 
term to a master tenant in exchange for rent paid to the 
owners of the real estate, including the holder of deedshare 
25. 

Master lease 28 preferably includes sublease provision 
28a, permitting the master tenant to sublease the real estate, 
maintenance provision 286, requiring the master tenant to 
maintain the real estate, insurance provision 28c, requiring 
the master tenant to insure the real estate, and tax provision 
2Sd, requiring the master tenant to pay taxes on the real 
estate. The master lease also may include guaranteed rent 
provision 28e, designating that the master tenant pay a 
predetermined guaranteed income to the holder of deedshare 
25, and credit rating provision 28/ requiring that the master 
tenant have a minimum credit rating of AA. Additionally, 
master lease 25 may contain extended term provision 2Sg, 
designating that the master lease extends beyond the term of 
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the master agreement, affecting the fair market value of the 
property, as discussed above. 

Referring now to FIGS. 4A-C, the steps taken by various 
parties in accordance with a preferred embodiment of the 
methods of the present invention are described. In FIG. 4A, s 
the steps taken by the seller of the deedshares, who may be 
the master tenant, are shown. First, at step 30, the seller 
purchases and aggregates a real estate portfolio having a 
predetermined value, e.g., $100 million. 

In step 31, the real estate portfolio is encumbered with a 10 
master agreement and master lease for a specified interval, 
e.g., 10 years. The master agreement includes a mechanism, 
discussed hereinabove, to reaggregate title from the holders 
of the deedshares to enable the real estate portfolio to be 
disposed of at the end of the term of the master agreement. 5 
In step 32, title to the real estate in the portfolio is divided 
into tenant-in-common deeds having a predetermined 
denomination, e.g., 1000 deeds each having a $100,000 
value, creating "deedshares." Finally, at step 33, the seller 
sells the deedshares to the public, either directly, or through 2Q 
qualified intermediaries via IRC §1031 exchanges. 

FIG. 4B shows the steps taken by the master tenant, 
starting with entering into the master lease, at step 40. 
During the term of the master lease, several steps are taken. 
At step 41, the master tenant pays monthly rent on the lease 25 
to the deedshare holders (co-tenants). The master tenant then 
subleases the property (typically at a profit) to one or more 
subtenants at step 42. In steps 43 and 44, the master tenant 
maintains the property, and pays the taxes and insurance on 
the property. When the term of the deedshare has expired, at 30 
step 45, the master tenant exercises his call to purchase the 
deedshares from the individual deedshare holders at a cal- 
culable value, such as fair market value. 

EIG. 4C shows the steps taken by a deedshare holder. At 
step 50, the deedshares are purchased from the seller, either 35 
directly, or through a qualified intermediary as part of an 
IRC §1031 exchange, as described in greater detail herein- 
below. During the term of the deedshares, the deedshare 
holder receives guaranteed monthly income from the rent 
paid by the master tenant (step 51). During the term of the 40 
deedshares, each deedshare holder is permitted to depreciate 
the deedshare holder's tax basis in any improvements on the 
property for tax-accounting purposes (step 52). At the end of 
the term, at step 53, the deedshare holder exercises his put 
to force the master tenant to purchase the deedshares at fair 45 
market value. Prior to the end of the term of the master lease, 
a deedshare owner may freely alienate title to the deedshare. 

It should be noted that in this preferred embodiment, if 
neither the put nor the call are exercised, the master tenant 
continues to pay rent to the deedshare holder to the end of 50 
the term of the master lease, and the deedshare holder 
continues to collect monthly income from the property, and 
yearly depreciation. Also, as discussed hereinabove with 
reference to FIG. 2, numerous modifications may be made to 
this arrangement. These modifications may include chang- 55 
ing the size of the real estate portfolio, the denominations of 
the deedshares, the term of the master lease, the term of the 
deedshares before the put/call may be exercised, the terms of 
the master agreement, and the mechanism by which title to 
the real estate portfolio may be reaggregate d. go 

Referring now to FIG. 5, the method of the present 
invention is described in the context of an IRC §1031 
exchange. Since deedshares represent an interest in invest- 
ment property, and the master agreement is designed to 
insure that the tenants-in-common do not acquire the 65 
attributes of a partnership, the deedshares are subject to 
tax-deferred treatment under IRC §1031. 



Exchanger 60 of investment real property A provides 
qualified intermediary 62 with the deed to relinquished 
property A. Qualified intermediary 62 then transfers title to 
property A to buyer 64 in exchange for money. In accor- 
dance with the principles of the present invention, seller 66 
of replacement property B encumbers property B with a 
master agreement, leases property B to a master tenant, and 
divides title in property B into tenant-in-common interests 
having predetermined denominations, to create deedshares. 

Seller 66 then conveys an appropriate value of deedshares 
to qualified intermediary 62. Exchanger 60 identifies the 
deedshares of the present invention as the replacement 
property for the exchange and obtains a mortgage commit- 
ment in an amount at least equal to the mortgage on 
relinquished property A. Once the purchase of the deed- 
shares "closes", qualified intermediary 62 transfers the deed- 
shares to exchanger 60, thereby completing the exchange. 

Applicants expect that there will be a ready market for 
deedshares, because there should be no difficulty identifying 
deedshares or closing on the identified deedshares within the 
time limits specified in IRC §1031. Moreover, applicants 
expect that by acquiring multiple deedshares (perhaps of 
different denominations) it will be easy to meet or exceed the 
value of the exchanged real estate using deedshares as the 
replacement property. Because the deedshares of the present 
invention represent an interest in real estate, they may be 
held subject to a mortgage, so the debt on the exchanged real 
estate also can be matched or exceeded, as required by IRC 
§1031. 

During the remaining portion of the specified term of the 
deedshares, exchanger 60 collects an income stream from 
his deedshares from master tenant 68, and may depreciate 
his interest in improvements on the replacement property B. 
When the deedshares reach maturity, or when exchanger 60 
decides to sell his deedshares, they may be sold for money, 
incurring tax liability at that time, or they may be exchanged 
for other deedshares or for other investment real estate 
through a further tax-deferred exchange under IRC §1031. 

A flowchart showing the individual steps in the process 
for performing an IRC §1031 exchange of investment real 
estate for deedshares is shown in FIG. 6. At step 70, the 
exchanger (i.e., exchanger 60 of FIG. 5) transfers the deed 
to the relinquished property to a qualified intermediary. 
Next, at step 71, the qualified intermediary sells the relin- 
quished property to a buyer, in exchange for money. Any 
mortgage on the relinquished property is paid from the 
proceeds of the sale. At this point, IRC §1031 specifies that 
the exchanger has 45 days to identify replacement property, 
and 180 days to close on the replacement property. 

In step 72, the exchanger identifies deedshares, as 
described hereinabove, to the qualified intermediary as the 
replacement property. To avoid boot, the identified deed- 
shares must have denominations that add up to a value at 
least equal to the value of the relinquished property, and 
must be subject to mortgages that will add up to a value at 
least equal to the value of the mortgage on the relinquished 
property In step 73, the qualified intermediary purchases the 
deedshares from a deedshare seller, closing the deal within 
the 180 day time limit specified in IRC §1031. Finally, in 
step 74, the qualified intermediary transfers the deedshares, 
subject to the appropriate mortgages, to the exchanger. 

Referring now to FIG. 7, an illustrative implementation of 
the investment instrument and methods of the present inven- 
tion is described. In FIG. 7, the properties and investors 
(deedshare holders) are tracked using a database application 
executed on a computer system. Database 80 contains four 
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inter-related sets of tables — property tables 82, investor 
tables 84, master tenant table 86, and mortgage tables 88. 

Each one of property tables 82 contains a list of properties 
associated with a single real estate portfolio that has been 
divided into deedshares, as described hereinabove. Each 5 
property in the list preferably includes information such as 
the name and address of the property, the type of property, 
the current income associated with the property, and the fair 
market value (as of last appraisal) of the property. Each 
property table, for example, may include information such io 
as the total value of the properties in the table (real estate 
portfolio), the total number and denominations of outstand- 
ing deedshares on the properties in the table, and the date at 
which the deedshares become subject to the put/call under 
the master agreement. In addition, each one of property 15 
tables 82 may be associated with a master tenant in master 
tenant table 86. 

Each one of property tables 82 is also associated with one 
of investor tables 84. Each investor table 84 preferably 
contains a list of all of the investors who hold deedshares in 20 
a particular real estate portfolio. For each investor, the 
database may include information such as the name and 
address of the investor, the number and denominations of 
deedshares held, the fair market value of the portion of the 
property associated with the deedshares (as of the last 25 
appraisal of the property), and the income provided to the 
investor based on the deedshares. 

Master tenant table 86 may be a single table containing a 
list of the master tenants associated with each of the real 

30 

estate portfolios. For each master tenant, database 80 pref- 
erably contains information such as the name and address of 
the master tenant, the credit rating of the master tenant (and 
any enhancement needed), and the rent paid by the master 
tenant under the master agreement. Alternatively, the iden- 
tity of the master tenant, and related information, may be 35 
combined into property tables 82. 

Mortgage tables 88 contain a list of the debt encumbering 
each investor's relinquished property and the debt associated 
with the deedshares held by each investor. This information 4Q 
may be used in conjunction with the information in property 
tables 82 to help investors assure that they obtain a sufficient 
mortgage on deedshares to comply with IRC §1031, and to 
assure lenders of the appropriate loan-to-value ratio which 
warrants the mortgage needed by investors. 45 

Database 80 may be used to generate reports required by 
applicable securities laws, as well as reports on the value of 
each real estate portfolio, the rental income due to each 
deedshare holder, certain information required by deedshare 
holders to complete their income tax returns, or any other 50 
useful compilation of the data contained in database 80. 
Additionally, database 80 may be linked to other databases 
(either directly or through a network, such as the Internet), 
such as the databases kept by master tenants, to keep track 
of subleases and maintenance. 5S 

Pertinent information from database 80 may be made 
available to investors. The data in database 80 also may be 
made available to qualified intermediaries, to be used in 
identifying which deedshares of various real estate portfo- 
lios best match the needs of potential investors for IRC 60 
§1031 exchanges, or for identifying potential master tenants 
or subtenants. 

It will be evident to one skilled in the art that there are 
other possible arrangements for the data in database 80. For 
example, the investor and property tables each may be 65 
organized as one large table, with each entry in the investor 
table having links to one or more of the entries in the 
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properties table, and each entry in the properties table having 
links to one or more entries in the investor table. Also, the 
investor table may be replaced with a deedshare table, listing 
the deedshares in each of the real estate portfolios, wherein 
each deedshare entry contains information on an investor. 
Additionally, the information contained in each table may be 
varied. For example, each entry in the investors table may 
contain additional information on the investor, such as age, 
current income (for tax purposes), and information on other 
properties and investments held by the investor. 

Referring to FIG. 8, an illustrative computer system and 
network for executing and accessing the database of FIG. 7 
is shown. Computer system 90 is a database server that 
executes the database described hereinabove. Computer 
system 90 includes CPU 91, which executes instructions that 
implement a database server application, and mass storage 
92, preferably a RAID array, on which the data that forms 
the database is stored. Computer system 90 also preferably 
includes network interface 93 so that the database may be 
accessed through other computers on a local area network. 

Computer system 90 also preferably includes communi- 
cation device 94, which may comprise a telephone modem, 
a cable modem, an ADSL modem, or any other device 
capable of communicating data between a computer and a 
wide area network. Communication device 94 is used to 
connect computer system 90 to a wide area network, pref- 
erably the Internet. This connection permits users at remote 
locations to access data in the database on computer system 
90. These users may include deedshare brokers, qualified 
intermediaries, master tenants, deedshare owners, or others 
who are entitled to access the information in the database. To 
prevent unauthorized access to data, computer system 90 
preferably executes security software as well as the database 
server application. 

Computer system 90 is preferably connected to a local 
area network, having multiple client computers 95, each of 
which may be used to access the database on computer 
system 90. Additionally, printer 96, which may be used for 
printing database reports or for printing certificates repre- 
sentative of deedshares, is connected to the local area 
network. Alternatively, printer 96 may be connected directly 
to computer system 90. 

Although preferred illustrative embodiments of the 
present invention are described above, it will be evident to 
one skilled in the art that various changes and modifications 
may be made without departing from the invention. It is 
intended in the appended claims to cover all such changes 
and modifications that fall within the true spirit and scope of 
the invention. 

What is claimed is: 

1. A method of creating a real estate investment instru- 
ment adapted for performing tax-deferred exchanges com- 
prising: 

aggregating real property to form a real estate portfolio; 

encumbering the property in the real estate portfolio with 
a master agreement; and 

creating a plurality of deedshares by dividing title in the 
real estate portfolio into a plurality of tenant-in- 
common deeds of at least one predetermined 
denomination, each of the plurality of deedshares sub- 
ject to a provision in the master agreement for re aggre- 
gating the plurality of tenant-in-common deeds after a 
specified interval. 

2. The method of claim 1, wherein encumbering the 
property in the real estate portfolio with a master agreement 
further comprises encumbering the real property with a 
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master lease to a master tenant who pays rent to holders of 
the deedshares. 

3. The method of claim 2, wherein creating the plurality 
of deedshares further comprises structuring the provision to 
include a put provision that allows holders of the deedshares 5 
to force the master tenant to purchase the deedshares at a 
calculable value after the specified interval and a call pro- 
vision that allows the master tenant to force holders of the 
deedshares to sell their deedshares to the master tenant at a 
calculable value after the specified interval. ^ 

4. The method of claim 2, wherein encumbering the real 
property in the real estate portfolio with a master agreement 
further comprises including a sublease provision in the 
master lease, enabling the master tenant to sublease the real 
estate. 

5. The method of claim 2, wherein encumbering the real 15 
property in the real estate portfolio with a master agreement 
further comprises including a maintenance provision in the 
master lease, requiring the master tenant to maintain the real 
estate. 

6. The method of claim 2, wherein encumbering the real 20 
property in the real estate portfolio with a master agreement 
further comprises including an insurance provision in the 
master lease, requiring the master tenant to insure the real 
estate. 

7. The method of claim 2, wherein encumbering the real 2 $ 
property in the real estate portfolio with a master agreement 
further comprises including a tax pro vision in the master 
lease, requiring the master tenant to pay taxes on the real 
estate. 

8. The method of claim 2, wherein encumbering the real ^ 
property in the real estate portfolio with a master agreement 
further comprises including an extended term provision in 
the master lease, designating that the master lease extends 
beyond the specified interval. 

9. The method of claim 2, wherein encumbering the real 
property in the real estate portfolio with a master agreement 35 
further comprises including a guaranteed rent provision in 
the master lease, designating that the master tenant pay a 
predetermined guaranteed income to holders of the deed- 
shares. 

10. The method of claim 2, wherein encumbering the real 40 
property in the real estate portfolio with a master agreement 
further comprises including a credit rating provision in the 
master lease, requiring that the master tenant have a speci- 
fied minimum credit rating. 

11. A method of performing a tax-deferred exchange of 45 
investment real estate under §1031 of the Internal Revenue 
Code comprising: 

transferring a first interest in investment real estate having 
a first value and being subject to a first debt from an 
exchanger to a third party; 50 

using the third party to transfer title to the first interest in 
investment real estate to a buyer in exchange for 
money, proceeds of the transfer of the title to the first 
interest being held by the third party; 

identifying deedshares having a second value equal to or 55 
greater than the first value and subject to a second debt 
equal to or greater than the first debt as a replacement 
property within a specified number of days of transfer- 
ring title to the first interest in investment real estate, 
the deedshares comprising an undivided tenant-in- 60 
common interest in investment real estate that is subject 
to a master agreement including a provision reaggre- 
gating title to the investment real estate represented by 
the deedshares at a specified time; 

closing the sale of the deedshares within a second speci- 65 
fied number of days of transferring title to the first 
interest in investment real estate; and 



788 Bl 

14 

transferring the deedshares and the second debt from the 
third party to the exchanger. 

12. The method of claim 11, wherein identifying deed- 
shares comprises identifying a combination of deedshares 
having different predetermined denominations that sum to 
the second value. 

13. The method of claim 11, wherein identifying deed- 
shares further comprises identifying deedshares subject to a 
master lease to a master tenant, and the master tenant pays 
rent to owners of the deedshares. 

14. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares subject to a 
provision for reaggregating title that comprises a put provi- 
sion that allows the owners of the deedshares to force the 
master tenant to purchase the deedshares at a calculable 
value on or after the specified time, and a call provision that 
allows the master tenant to force the owners of the deed- 
shares to sell their deedshares to the master tenant at a 
calculable value on or after the specified time. 

15. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision enabling the master tenant to sublease the real 
estate. 

16. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision requiring the master tenant to maintain the real 
estate. 

17. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision requiring the master tenant to insure the real 
estate. 

18. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision requiring the master tenant to pay taxes on the real 
estate. 

19. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision that the master lease extends beyond the specified 
interval. 

20. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision that requires the master tenant has a specified 
minimum credit rating. 

21. The method of claim 13, wherein identifying deed- 
shares further comprises identifying deedshares including a 
provision to appoint a real estate broker to sell the real estate 
after title to the real estate has been re aggregated at the 
specified time. 

22. A method of creating a real estate investment instru- 
ment adapted for performing tax-deferred exchanges com- 
prising: 

acquiring real property; 

encumbering the real property with a master agreement; 
and 

creating a plurality of deedshares by dividing title in the 
real property into a plurality of tenant-in-common 
deeds of at least one predetermined denomination, each 
of the plurality of deedshares subject to a provision for 
reaggregating the plurality of tenant-in-common deeds 
after a specified interval. 

23. The method of claim 22, wherein encumbering the 
real property with a master agreement further comprises 
encumbering the real property with a master lease to a 
master tenant who pays rent to holders of the deedshares. 

24. The method of claim 23, wherein creating the plurality 
of deedshares further comprises structuring the provision to 
include a put provision that allows holders of the deedshares 
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to force the master tenant to purchase the deedshares at a 
calculable value after the specified interval and a call pro- 
vision that allows the master tenant to force holders of the 
deedshares to sell their deedshares to the master tenant at a 
calculable value after the specified interval. s 

25. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 
including a sublease provision in the master lease, enabling 
the master tenant to sublease the real property. 

26. The method of claim 23, wherein encumbering the 10 
real property with a master agreement further comprises 
including a maintenance provision in the master lease, 
requiring the master tenant to maintain the real property. 

27. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 15 
including an insurance provision in the master lease, requir- 
ing the master tenant to insure the real property. 

28. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 
including a tax provision in the master lease, requiring the 20 
master tenant to pay taxes on the real property. 

29. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 
including an extended term provision in the master lease, 
designating that the master lease extends beyond the sped- 25 
fied interval. 

30. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 
including a guaranteed rent provision in the master lease, 
designating that the master tenant pay a predetermined 30 
guaranteed income to holders of the deedshares. 

31. The method of claim 23, wherein encumbering the 
real property with a master agreement further comprises 
including a credit rating provision in the master lease, 
requiring that the master tenant have a specified minimum 35 
credit rating. 

32. A method of creating a real estate investment instru- 
ment adapted for performing tax-deferred exchanges com- 
prising: 

acquiring real property; 40 

encumbering the real property with a master agreement; 
and 

using a computer to generate a plurality of deedshares by 
generating a plurality of tenant-in-common deeds of at 45 
least one predetermined denomination that divide title 
in the real property into a plurality of tenant-in- 
common interests, each of the plurality of tenant-in- 
common deeds being subject to a provision in the 
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master agreement for reaggregating the plurality of 
tenant-in-common deeds after a specified interval. 

33. The method of claim 32, wherein encumbering the 
real property with a master agreement further comprises 
encumbering the real property with a master lease to a 
master tenant who pays rent to holders of the deedshares. 

34. The method of claim 33, wherein using a computer to 
generate the plurality of deedshares further comprises 
including in the master agreement a put provision that 
allows holders of the deedshares to force the master tenant 
to purchase the deedshares at a calculable value after the 
specified interval and a call provision that allows the master 
tenant to force holders of the deedshares to sell their 
deedshares to the master tenant at a calculable value after the 
specified interval. 

35. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including a sublease provision in the master lease, enabling 
the master tenant to sublease the real property, 

36. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including a maintenance provision in the master lease, 
requiring the master tenant to maintain the real property. 

37. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including an insurance provision in the master lease, requir- 
ing the master tenant to insure the real property. 

38. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including a tax provision in the master lease, requiring the 
master tenant to pay taxes on the real property. 

39. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including an extended term provision in the master lease, 
designating that the master lease extends beyond the speci- 
fied interval. 

40. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including a guaranteed rent provision in the master lease, 
designating that the master tenant pay a predetermined 
guaranteed income to holders of the deedshares. 

41. The method of claim 33, wherein encumbering the 
real property with a master agreement further comprises 
including a credit rating provision in the master lease, 
requiring that the master tenant have a specified minimum 
credit rating. 

^ 3^ 3^ jf( 3£ 
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ABSTRACT 



A system for managing conditional purchase offers is dis- 
closed where an individual searching for a ticket to a 
particular event may provide a guaranteed purchase offer to 
a plurality of potential sellers. Various methods and systems 
for completing such a transaction are also disclosed. An 
exemplary method includes: making available a guaranteed 
purchase offer to a plurality of potential sellers; potential 
sellers examining offers corresponding to a ticket they 
possess; and a potential seller providing an acceptance to the 
guaranteed purchase offer. The disclosure describes a 
method of payment whereby both the buyer and seller must 
provide credit card pre-autborization to ensure payment and 
delivery of the ticket. Also, one embodiment discloses a 
delivery of the ticket that includes the participation of the 
venue hosting the event. In this embodiment, the traditional 
practice of exchanging tickets for cash is replaced with an 
electronic serial number system. According to this system, 
the venue may be notified to cancel the serial number 
originally assigned to the ticket held by the seller, and 
re-assign a new serial number directly to the buyer. The 
buyer may then exchange this number for a ticket at the 
venue box office. 

12 Claims, 18 Drawing Sheets 
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TICKET, CENTRAL CONTROLLER TRANSMITS NAME OF USER BUYING THE 

TICKET TO VENUE CONTROLLER ^ 



VENUE CONTROLLER CREATES A NEW RECORD IN THE REPLACEMENT TICKET 
TABLE INDICATING NAME, ORIGINAL TICKET NUMBER AND SEAT NUMBER FIELDS 

2M 



I 



VENUE CONTROLLER ASSIGNS NEW SEAT CODE, STORES CODE IN NEW SEAT 
CODE FIELD OF REPLACEMENT TICKET DATABASE AND TRANSMITS NUMBER TO 
CENTRAL CONTROLLER ™ 




TO FIG. 7g 



FIG. 7f 
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F J FROM FIG. 7f 




CENTRAL CONTROLLER UPDATES THE NEW TICKET NUMBER FIELD OF THE 
TRANSACTION DATABASE WITH THE NEW SEAT CODE TRANSMITTED BY THE 

VENUE CONTROLLER jfifi 

j 



CENTRAL CONTROLLER CHARGES CREDIT CARD OF THE USER BUYING THE 
TICKET THE PRICE OF THE TICKET AND A PROCESSING FEE yog 



NOTIFY USER SELLING THE TICKET THAT PAYMENT WILL BE TENDERED WHEN 

ORIGINAL TICKET HAS BEEN SURRENDERED 



CENTRAL CONTROLLER NOTIFIES USER BUYING THE TICKET THAT HIS 

GUARANTEED OFFER HAS BEEN ACCEPTED AND TRANSMITS 
THE TICKET CODE 794 

^ 



USER BUYING THE TICKET PRINTS TICKET CODE AND BRINGS TO VENUE TO 

GAIN ACCESS TO EVENT m 



I 



CENTRAL CONTROLLER RECEIVES TICKETS AND CREDITS THE ACCOUNT OF 

THE USER SELLING THE TICKET THE PRICE OF THE TICKET(S) LESS A 
PROCES SING FEE 798 

1 




END OFFER REVIEW PROCESS 



FIG. 7g 
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CONDITIONAL PURCHASE OFFER 
MANAGEMENT SYSTEM FOR EVENT 
TICKETS 

CROSS-REFERENCE TO RELATED s 
APPLICATIONS 

This is a continuation-in-part of U.S. Patent Application 
Ser. No. 08/889,319 filed Jul. 8, 1997 USP 6,085,169 which 
is a continuation-in-part of U.S. Patent Application Ser. No. 
08/707,660 filed Sep. 4, 1996 USP 5,794,207 and U.S. 10 
application entitled "Method and System for Controlling 
Access to a Venue using Alterable Tickets," U.S. Patent 
Application Ser. No. 08/916,656 (Attorney Docket No. 
"WD2-97-052") filed Aug. 22, 1997, each incorporated by 15 
reference herein. 

The present invention is related to the following United 
States Patent Applications filed contemporaneously here- 
with: "Conditional Purchase Offer Management System for ^ 
Packages," U.S. Patent Application Ser. No. 08/923,317 
(Attorney Docket No. WD2-97-065); "Conditional Purchase 
Offer Management System for Telephone Calls/' U.S. Patent 
Application Ser. No. 08/923,317 (Attorney Docket No. 
WD2-97-028); "Conditional Purchase Offer Management 25 
System for Cruises," U.S. Patent Application Ser. No. 
08/923,618 (Attorny Docket No. WD2-97-069); and "Con- 
ditional Purchase Offer and Third-Party Input Management 
System," U.S. Patent Application Ser. No. 08/923,524 
(Attorney Docket No. WD2-97-067), each assigned to the 30 
assignee of the present invention and incorporated by ref- 
erence herein. 

TECHNICAL FIELD 

35 

This invention relates generally to a method and system 
for facilitating the remote purchase and sale of tickets, and 
more particularly, to a method and system for electronically 
facilitating buying and selling tickets for an event, such as 
the ballet, theater or a sporting event. 40 

DESCRIPTION OF THE RELATED ART 

Attending an event such as a concert, play, or sporting 
event generally requires purchasing a ticket in advance. 45 
Tickets are traditionally provided by the venue hosting the 
event and are sold at the venue's box office. Tickets are also 
available through ticket distributors, in coordination with the 
hosting venue and the event promoter. Aside from the venue 
box office, tickets are also available through ticket outlets, 50 
ticket brokers, telephone sales, remote ticket printing 
applications, ticket kiosks and Internet web sites. 

It is not uncommon, however, for a venue to sell out 
quickly for a particular event, whereby available tickets are 55 
limited to ticket brokers and "scalpers." For instance, a 
popular concert may sell out well before many people 
interested in attending are aware that the original tickets are 
available. Thus, these individuals are forced to explore the 
resale market. 60 

Resellers of tickets are limited in their ability to advertise 
availability to the public. Resellers may rely on classified 
advertisements in the newspaper, electronic bulletin boards, 
established contacts or "chat rooms" on the Internet. Also, $5 
resellers usually must complete sales either through the 
mail, or in person. 
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A number of shortcomings, however, exist for both buyers 
and sellers in the present resale market. First, the aforemen- 
tioned methods of advertising are generally neither efficient 
nor flexible. The cost of advertising often outweighs the 
marginal profit gained through advertising, particularly for a 
single ticket. For instance, an advertiser may pay $30 for a 
classified ad that results in an additional profit of only $15. 
Moreover, advertisements are difficult to remove from the 
public realm once tickets are resold. Thus, a person selling 
a ticket may get many telephone inquiries after the ticket has 
been sold. Further, advertising is especially difficult because 
many transactions need to be completed just before an event 
occurs. This is problematic because the buyer requires the 
ticket to attend the event, and delivering the ticket imme- 
diately prior to the event may be difficult. Presently, ticket 
sellers are often forced to leave tickets at will-call windows 
or with local proprietors for pick up. 

Related shortcomings with the current resale market are 
timing and delivery. Ticket resellers may not have tickets 
available until very near to the start time of a particular 
event, and buyers may not decide to attend an event until 
shortly before it begins. Specifically, the prior art does not 
allow substantially immediate efficient consummation of an 
offer to purchase or sell tickets. Accordingly, there is not a 
system that solves the problems associated with reselling 
tickets on the day of the event. 

For example, if a person holding a ticket to a hockey game 
discovers two hours before the game begins that he cannot 
attend, his options for reselling his ticket are severely 
limited. His best chance to resell his ticket is to stand outside 
the arena and hope to find a buyer for the ticket. Such 
conduct is illegal in most states. Using a similar example, if 
a person decides he would like to attend that game two hours 
before it begins, his best option to acquire a ticket is to 
appear outside the arena and search for a ticket reseller. In 
both cases, the options presented to both the buyer and the 
seller are limited to particularly inconvenient and unpredict- 
able ways of purchasing and reselling tickets. 

Finally, potential buyers often possess a general distrust of 
ticket resellers. The act of ticket reselling is often perceived 
as illegal, and potential buyers are sometimes unhappy about 
resale prices that are significantly higher than those origi- 
nally determined by the venue. As a result, buyers simply do 
not trust ticket resellers, but are often forced to use them as 
a last resort to purchase tickets. Markups on marquis events 
can often be as high as 500%. Further, unless a buyer is 
face-to-face with a ticket reseller, the buyer is typically 
unwilling to pay for tickets without some assurance of 
delivery. Likewise, a ticket reseller is typically unwilling to 
deliver tickets without payment in advance. 

SUMMARY OF THE INVENTION 

The problems identified above are solved and a technical 
advance is achieved by providing, in accordance with the 
present invention, a system and method for purchasing a 
ticket for a specified event on a specified date at a specified 
price. 

A method according to the preferred embodiment of the 
present invention includes: a potential buyer electronically 
transmitting a guaranteed purchase offer for a ticket to a 
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central controller; the central controller electronically mak- 
ing the offer available to a plurality of potential sellers; a 
first-accepting seller transmitting an acceptance of the offer 
to the central controller; and the central controller transmit- 
ting this acceptance to the buyer along with a code to use at 
a venue to verify his purchase of the ticket. 

Thus, the preferred embodiment of the present invention 
provides individuals a quick and easy way to purchase a 
ticket from a ticket reseller, and allows them to avoid the 
traditional problems of the ticket resale market. Moreover, 
ticket resellers can sell a ticket based on a guaranteed 
purchase offer provided by a potential buyer. In addition, the 
present invention includes mechanisms which prevent fraud 
both during and after the transaction. 

Further aspects of the present invention will become 
apparent during the course of the following detailed descrip- 
tion and by reference to the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic view of a system according to one 
embodiment of the present invention; 

FT G. 2 is a schematic view of a central controller used in 
the system of FIG. 1; 

FIG. 3 is a schematic view of a remote user terminal used 
in the system of FIG. 1; 

FIG. 4 is a schematic view of a venue controller used in 
the system of FIG. 1; 

FIG. Sa is a table illustrating the contents of an event table 
used in the system of FIG. 1; 

FIG. Sb is a table illustrating the contents of a venue table 
used in the system of FIG, 1; 

FIG. 5c is a table illustrating the contents of a customer 
table used in the system of FIG. 1; 

FIG. Sd is a table illustrating the contents of an offer table 
used in the system of FIG. 1; 

FIG. Se is a table illustrating the contents of a transaction 
table used in the system of FIG. 1; 

FIG. 6a is a table illustrating the contents of a ticket table 
used in the system of FIG. 1; 

FIG. 6b is a table illustrating the contents of a replacement 
ticket table used in the system of FIG. 1; and 

FIGS, la-lg are flow diagrams depicting a method of 
submitting and accepting a guaranteed offer to buy an event 
ticket over the Internet according to one embodiment of the 
present invention. 

DETAILED DESCRIPTION 

A method and apparatus of the present invention will now 
be discussed with reference to FIGS. l-7g. The present 
invention allows a buyer to present a guaranteed purchase 
offer for a ticket to a certain event, such as a hockey game, 
to a number of potential sellers. The sellers may review the 
offer, and accept the offer if the terms are agreeable. Thus, 
a buyer may quickly submit an offer to purchase tickets 
which are guaranteed to be delivered in a safe, convenient 
manner. 

System Architecture 

With reference to FIGS. 1-6, the system architecture of 
one embodiment of the apparatus and method of the present 
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invention is illustrated. As shown in FIG. 1, the apparatus of 
the present invention generally comprises a venue controller 
400, a central controller 200, a credit card processor 230 and 
a remote user terminal 300. The remote user terminal 300 is 
5 connected to the central controller 200 through a network 
245. 

Using the above components, the present embodiment of 
the invention provides a method and apparatus to allow a 
central controller to facilitate the purchase and sale of event 

10 

tickets. Specifically, central controller 200 receives and 
posts offers to purchase tickets for a particular event. Such 
offers are guaranteed, for example, using a line of credit on 
a credit card account. Central controller 200 further makes 

15 each offer available to a plurality of potential sellers, and 
allows sellers to accept the offer and thereby form a legally 
binding contract. 

As shown in FIG. 2, central controller 200 includes 
central processing unit (CPU) 205, random access memory 

20 (RAM) 215, read only memory (ROM) 220, clock 235, 
input/output ("I/O") port 255, and data storage device 250. 
The data storage device 250 is a memory device containing 
an event table 500, a venue table 520, a customer table 530, 
an offer table 550, and a transaction table 580, discussed in 

25 greater detail with reference to FIGS. Sa through Se, respec- 
tively. 

Central Controller Data Tables 
FIG. Sa illustrates an exemplary event table 500 that 

30 preferably stores information on events for which tickets 
may be resold using the system of FIG. 1, including location 
and scheduling information. Event table 500 maintains a 
plurality of records, such as record 514, each associated with 
a different event. For each event identifier listed in event ID 

35 field 502, event table 500 includes an event type code stored 
in field 504 and an event description stored in field 506, The 
event type code stored in field 504 represents the format of 
the event, for instance, a National Hockey League game is 

4Q denoted as "NHL." The event description stored in field 506 
describes the specific event. 

Event table 500 also preferably includes a venue ID stored 
in field 506. The venue ID stored in field 506 may be 
utilized, for example, to index venue table 520, more fully 

45 described with reference to FIG. Sb. As shown in FIG. Sa, 
each record stored in event table 500 further includes a date 
stored in field 510 and a time stored in field 512. The date 
and time of fields 510 and 512, respectively, represent the 
starting time of the event associated with the record. The 
information stored in this table may be supplied to the 
central controller 200 from any number of sources, includ- 
ing promoters, venues and potential buyers and sellers. 
FIG. Sb illustrates an exemplary venue table 520. Each 

55 record of venue table 520, such as record 528, preferably 
stores data associated with and describing a venue. Venue 
table 520 is preferably indexed by field 522 which stores a 
unique venue identifier. Venue table 520 further stores a 
theater, auditorium or stadium name in field 524 and an 

60 address in field 526. 

FIG. 5c illustrates an exemplary customer table 530 
which preferably stores information on each customer reg- 
istered with the electronic ticket sales system. Customer 

6 5 database 530 maintains a plurality of records, such as 
records 546 and 548, each associated with a different cus- 
tomer. Customers registered in customer table 530 may buy 
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tickets, sell tickets or both buy and sell tickets. Customer Once an offer is accepted, central controller 200 adds a 

table 530 stores a unique customer identifier for each transaction record to transaction table 580. FIG. Se illus- 

customer in field 532 and name and address information in trates an exemplary transaction table 580 that preferably 

fields 534 and 536. Preferably, the data maintained in stores information relating to each accepted offer. Each 

customer table 530 is provided by the customer during a * accepted offer is assigned a unique transaction identifier that 

registration process, at which time the customer is assigned is stored in field 581 of transaction table 580 and field 567 

a unique customer identifier. of offer table 550. An offer identifier of an associated record 

Customer table 530 further stores customer credit card in offer table 550 is stored in field 582. This offer identifier 

data. The customer's credit card number is stored in field may be used as an index into offer table 550 to retrieve 

10 

538. The expiration date of the customer's credit card is information regarding the offer associated with a transaction 

stored in field 540, and the name of the cardholder as it record. 

appears on the credit card is stored in field 542. Each record of transaction table 580 preferably further 

FIG. 5^ illustrates an exemplary offer table 550 that includes field 583 which stores the date the associated offer 

preferably stores information relating to offers posted using 35 was accepted and field 584 which stores the total value of the 

the ticket sales system of the present embodiment. Offer transaction. Field 585 stores the amount charged to the 

table 550 maintains a plurality of records, such as records buyer's credit card; field 586 stores the amount of the 

570 and 572, each associated with an offer to buy or sell seller's credit line reserved to support the acceptance; and 

tickets. Each record of offer table 550 includes a unique offer field 587 stores the fee charged for processing the transac- 

identifier stored in field 551 that is assigned by central 20 tion. Each record of transaction table 580 also stores a date 

controller 200 when the offer is posted. Each record of offer in field 588 indicating the date the ticket(s) are received by 

table 550 includes fields for identifying the customer making the operator of central controller 200. 

the offer, conditions of the offer, the customer accepting the The customer identifier of the seller is stored in field 589, 

offer, and administrative information related to the offer. and data identifying the tickets) is stored in fields 590 and 

The customer identifier of the customer extending the 25 594. Field 590 stores the original ticket numbers), and field 

offer is stored in field 552. Information relating to the 594 stores new ticket number(s). The new ticket numbers are 

customer extending the offer may be easily obtained using assigned to distinguish original tickets from resold tickets 

the customer identifier of field 552 as an index into customer aQci promote efficient resolution of potential conflicts 

table 530. Each record in offer table 550 further stores an 30 between ticket holders. 

event identifier in field 553. The event identifier indicates the Optionally, central controller 200 may include a contract 

event to which the offered ticket(s) relate. Information detail table (not shown) containing form contract provisions 

regarding the event may be easily obtained using the event which the <* ni ™ 1 P™ cessor 200 retrieves and transmits to 

identifier of field 553 as an index into event table 500. users f 1 vanous For exam P le ' ^ M& ma y 

r, , j r cc * Li «n c. • ij n \i eeA <>c include a contract provision that is transmitted to a buyer and 
Each record of offer table 550 further includes fields 554 35. . < ■ T j * ™. 
j *u * * ,1 « . , , iL , . incorporated into the guaranteed purchase oner. The contract 
and 555 that store the date the offer was made and the last , , . 1 ■ 1 f . . . . ■ . . . . 
, ...<«> , ,1 - , ^ ta °l e ma y also include a contract provision which is trans- 
day on which the offer may be accepted, respectively. Data . . . 1t . t A , - . - 
. . „ . «. , . mitted to a seller prior to requesting an acknowledgment of 
indicating an offer type and offer status are also stored m his ^ tQ bind a buyer , s offer ^ create a lega]ly binding 

each record of offer table 550 in fields 556 and 557. Field 4Q CQntract These form provisions effec tively fill the gaps 

556 stores a code indicating whether the offer is an offer to between mimoiss spe cified by the buyer, specifying the 

buy or an offer to sell one or more tickets. Field 557 stores generic contract details common to most contracts of this 

a code indicating the status of the offer. Offer status possi- nature. 

bilities include; pending, active, expired and fulfilled. Tj ser Terminal 

Field 558 of each record in the offer table stores the 45 Referring now to FIG. 3, remote user terminal 300 will 

number of seats to which the offer applies. Data identifying now be described in greater detail. Remote user terminal 300 

the location of seats related to the offer populate fields can be a personal computer, screenphone, stand alone kiosk, 

559-564. In the event an offer requires a range of seat or any other device through which a customer can access the 

locations, data stored in fields 559-561 are used to identify central controller 200. Remote user terminal 300 generally 

the first seat in a range, and data stored in fields 562-564 are includes a central processing unit ("CPU") 305 that controls 

used to identify the last seat in a range. Field 565 stores the the operation of remote user terminal 300. CPU 305 is 

price per seat. electronically connected to a random access memory 

In addition, each record of offer table 550 includes ("RAM") 315, a read only memory ("ROM") 320, an 

administrative data in fields 566-569. Data stored in field 55 input/output port 325, a clock 335, a communication port 

566 stores an amount of credit authorized to support the 340 and a data storage device 360. CPU 305 receives inputs 

offer. Once an offer has been accepted, field 567 stores a from a remote user with the input/output port 325 and an 

transaction identifier that may be used as an index into input device 345, such as a keyboard. CPU 305 transmits 

transaction table 580, discussed more completely with ref- outputs to a remote user via the input/output port 325 and a 

erence to FIG. Se. Each record of offer table 550 optionally 60 video monitor 330. Further, the communication port 340 

stores a pointer to a related, or linked, offer record. The provides the communication path to network 245. Finally, 

pointer is stored in field 568 and represents the offer iden- the data storage device 360 is a memory device containing 

tifier of the next related record in offer table 550. Finally, central controller interface software 365. 

field 569 of each record of offer table 550 stores one or more 65 Venue Controller 

serial numbers of the original tickets that a seller would like Referring now to FIG. 4, venue controller 400 will now be 

to sell. described in greater detail. Venue controller 400 generally 
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includes a central processing unit ("CPU") 410 that controls to pay for the requested tickets. The guaranteed purchase 

the operation of venue controller 400. The CPU 410 is offer is then made available to potential sellers by posting 

electronically connected to a random access memory the offer using the web site linked to central controller 200. 

("RAM") 420, a read only memory ("ROM") 430, a clock Periodic maintenance is performed by central controller 200 

440, a communication port 450 that provides a communi- 5 l0 ensure that "active" offers have not expired. A potential 

cation path to central controller 200, and a data storage seller can use the system of the present invention to browse 

device 460. Data storage device 460 is a persistent memory offcrs ^ submit an electronic acceptance of a desirable 

device containing a ticket table 610 and a replacement ticket offef ^ acceptance by the potential seller ^ transmitted 

table 630. Venue controller 4(M) furUier includes input device electronicall t0 central controller 2 00. Central controller 

480 for receiving input data and output device 470 for inn ♦ j * * *u n * j-* 

, . & , ? . r r 200 processes the acceptance and contacts the seller s credit 

presenting or displaying information to an operator. /. . ..... • • . . -. . 

i-t^ -.i . / 1 ... 4 ;,, . card issuer to ensure that there is sufficient credit to cover a 

FIG. ba illustrates an exemplary ticket table 610 that . , , . e ^ . „ 

c . . , j . u i * ■ j£ ■ potential penalty for non-performance. This reservation or 

preferably stores information about tickets issued for various 

seats at a particular venue. Each ticket has a specific ticket „ the ^ s credlt 13 mtended to P romote between the 

number assigned to it by venue controller 400 prior to P arties ^ P rotect the After verifying 

issuance. Each record of ticket table 610 preferably includes available credit, both parties are notified of the binding 

field 611 that identifies the event for which the ticket is valid, transaction, and the tickets are electronically voided and 

field 612 that identifies the number assigned to each ticket assigned a replacement ticket number. The seller is then 

issued for an event, and fields 614-620 that represent the 20 required to surrender the voided tickets. This may be accom- 

location of the seat in the auditorium (i.e. the section, row plished by returning them to the venue, or the seller may 

and seat, respectively). Ticket table 610 could also contain mail the tickets to the operator of central controller 200. 

fields representing other information specific to a venue, an Upon receiving the surrendered tickets, the operator of 

event, or a seat. central controller 200 directs payment to be transferred to 

FIG. 6b illustrates an exemplary replacement ticket table 25 the user selling the tickets. 

630 that preferably stores data relating to original ticket With reference to FIG. la, a process by which a user logs 

numbers that have been voided and assigned replacement on and begins using the system will now be described. As 

ticket numbers. Replacement ticket table 630 stores the shown in step 700, a user operating a remote terminal 300 

ticket numbers that have been resold by the central control- 30 establishes a connection with the central controller 200 

ler 200 in field 632 and stores the replacement ticket through network 245. The user may be either a potential 

numbers in field 642. Each record of ticket table 630 further buyer wishing to place a guaranteed purchase offer for 

includes a field 631 that stores an event identifier and a field tickets, or a potential seller wishing to review offers for 

640 that stores a buyer identifier. tickets. 

It will be recognized by one of ordinary skill that the 35 At step 702, central controller 200 requests a customer ID 

present invention could be constructed and operated without from the user. At step 704, central controller 200 determines 

the illustrated distributed processing architecture. If venues how to proceed based on whether or not the user already has 

and ticket distributors so desired, central controller 200 a customer ID. If the user is registered with this service, and 

could incorporate all or part of the database of venue 4Q remembers his customer ID, he transmits his customer ID to 

controller 400 and perform all or part of the processing steps central controller 200 at step 712, and the process continues 

performed by venue controller 400 in the present embodi- with step 714. 

ment. In such an alternate embodiment, data processing and If, on the other hand, the user is not registered with the 

data storage could be centralized, and venues could access service, or does not remember his customer ID, he must 

the data as appropriate using conventional remote terminals 45 submit a negative response at step 704 and present relevant 

or work stations. customer information to central controller 200, as shown by 

Online Embodiment step 706. At step 708, central controller 200 creates a record 

In one embodiment of the present invention, communi- of the customer based on the received customer information, 

cations between potential buyers and sellers take place via This information, including name, address, credit card and 

an electronic or digital network, such as the Internet, with number, expiration date, and name as it appears on the credit 

central controller 200 hosting an Internet web site that users card, is stored in customer table 530. At step 710, central 

can access or "log on" to by means of a personal computer. controller 200 compares the information provided by the 

It is important to note that users can access the central user with information already stored in customer table 530. 

controller via other communications links such as a conven- 55 If a match is found, central controller 200 retrieves the 

tional telephone line linked to a voice response unit customer ID from field 532 of customer table 530, and 

("VRU"). transmits the customer ID number to the user. This service 

To use the ticket reselling service, a user who is a potential is provided for users who have given information previously, 

buyer logs on to central controller 200 through network 245, but do not remember their customer ID number. If no match 

creates and submits a guaranteed purchase offer, and dis- 60 is found, the central controller 200 assigns a new customer 

connects from the network 245. In one embodiment, a ID to the user, stores it in field 532 of customer table 530, 

guaranteed purchase offer is a legally binding offer to and transmits it to the user. 

purchase tickets that is backed by a pre-authorized credit At step 714 the user indicates whether he would like to 

card transaction. Upon receiving the offer, central controller 55 submit a guaranteed purchase offer, or review offers from 

200 contacts the buyer's credit card issuer to ensure that the potential buyers. The process steps relating to submitting 

buyer has a valid credit card account and/or sufficient credit offers are described more fully with reference to FIGS. 
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lb-lc. The process steps relating to reviewing offers are multiple sections instead of specific seats, he can enter a 

described more fully with reference to FIGS, ld-1%. In an range of selections. Central controller 200 then stores this 

alternative embodiment, the user could also elect to adver- broader selection by only using the section fields 559 and 

tise the availability of tickets for a certain event to potential 562, and leaving the other four fields empty, 

buyers. Furthermore, a user could elect to review such 5 Further, the user may provide a close date to denote a date 

advertisements, to get a better understanding of what a fair on which ^ offer expires. As previously discussed, central 

price might be, prior to submitting an offer. controller 200 periodically reviews this close date, and 

FIGS, lb and 7c illustrate the process steps executed changes the status of the offer to "expired" in field 557 of the 

following the user's choice at step 714 to submit a guaran- 10 ° ffer table 550 0DCe ^ datC haS . 

teed purchase offer. At step 716, the central controller . , At ste P 722 ' centra j 200 receives the offer 

, , * information transmitted by the user, and as shown in step 

transmits general venue and event information to user ter- A , t „ „_l , * * «- . 

• , **J? r . , ^ • 724, central controller 200 creates a record of the offer in 

minal 300 for display to the user. For instance, in one „. ' U1 „~ A , , . , 1JV1 

t , „ . , , offer table 550. At step 728, the user is asked if he would like 

embodiment, central controller 200 may provide a number tQ make additional offcR3 At tnispomt) if the user would like 

of options to the user in order to pinpoint the specific event tQ make an offer fof a ^ eventj hc may gQ ^ 

that the user would like to attend. The user could directly same process discussed m steps 7 i 6 _72 4 . However, if the 

request a particular event, or proceed through a group of user would likc to make a related) or linkcd offer to the offer 

narrowing choices to ultimately find the right event. A user, previously provided, they may do so as follows. First, in one 

for example, may be asked to identify any of the fields from 20 embodiment they provide the same event ID as at step 718. 

event table 500. Depending on the amount of information Next, after submitting the same general information previ- 

provided, the choice of events will be narrowed accordingly. ously discussed, the user indicates that this offer is linked. 

For instance, if the user provides only the event type (e.g. The central controller then assigns the offer ID number 

"NHL"), central controller 200 scans the event table 500 and created for the initial offer as the link ID number for the 

provides all matches found in the event type field 504. This 25 related offer, and stores in the link ID field 568 of the offer 

may be a long list of events, however, central controller 200 table 550. 

may prompt the user for more information to narrow the list. A user might provide a linked offer based on the type of 

The user may then select from the narrow list to find the seat desired. For instance, the user might select a number of 

event for which he is looking. For example, the user may 3Q the "high quality" seats in a particular venue, and offer a 

specify only Saturday matinee performances of a particular higher purchase price. The linked offer would include 

Broadway production in order to narrow the list. Central "lower quality" seats for a particular venue, perhaps at a 

controller 200 then provides the user with the correct event lower purchase price. Thus, based on the link ID, potential 

information, including the event ID from field 502 of the sellers will consider both offers together during their review, 

event table 500. The user includes this event ID as part of 35 Also, the user may link offers for two separate events as 

their guaranteed purchase offer so that it may be tracked by opposed to the same one. For example, instead of linking 

central controller in the offer table 550. offers based on seat selection and price, the user may prefer 

Next, at step 718, the user selects the desired event based to attend one of two events in the local area, but not both, 

on the event ID number. At step 720, central controller 200 4Q Thus, he could link these offers so that potential sellers 

requests certain information from the user pertaining to the would be made aware that the offers were conditioned 

offer, such as against an "either/or" proposition. 

(1) the number of tickets desired; The central controller 200 assigns an offer ID number to 

(2) the price for each ticket; each offer in the offer ID field 551, and assigns this number 

(3) the location desired for each ticket; and 45 as the link ID number for linked offers in link ID field 568. 

(4) optionally, a date through which the offer is valid. Also, the offer date field 554 is populated with a timestamp 
The user indicates the number of tickets he would like and (e.g., date and time) indicating when the offer was posted. 

the price he is willing to spend, based on the particular Next, central controller 200 assigns the value "pending" to 
location of the tickets. The user may choose the exact the status field 557. This value will change to "active" upon 
location of seats that correspond to the price he is willing to receipt of authorization from the user's credit card issuer, 
pay using a graphical representation of the venue. For Further, central controller 200 calculates the authorized 
instance, based on the venue ID number (stored in field 522 amount, and stores it in authorized amount field 566. The 
of venue table 520), central controller 200 retrieves from authorized amount field represents the amount of the user's 
memory and provides to the user at remote user terminal 300 55 credit which is reserved to "back up" the offer and is usually 
a graphical representation of seating at that particular venue. equal to the total transaction amount. By reserving a portion 
In one embodiment, central controller 200 first provides a of the user's credit, the ticket seller and ticket service can be 
broad general outline of the entire venue (e.g., display by guaranteed that they will receive payment if the offer is 
sections). The user can then click on a particular area to accepted. In case of linked offers to buy, the authorized 
narrow his search for exact seats. With each successive 60 amount is the highest transaction amount of the linked 
selection click, the display screen at user terminal 300 offers. When a linked offer is accepted, the system auto- 
narrows the scope of displayed seating until the user finds matically considers all related offers to be withdrawn, 
the seats he desires. The user can then select the group of Finally, central controller 200 stores all the information 
seats which corresponds to the purchase offer. Central con- 65 provided by the user, including the seat location based on the 
troller 200 stores the selected seats in fields 559-564 of the graphical representation of the venue, in the respective fields 
offer table 550. If the user prefers to select one section or of the offer table 550. 
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At step 730, the central controller 200 extracts legal central controller 200 allows associated linked offers to be 

contract language from the contract detail table (not shown) reviewed simultaneously, so that the user can compare the 

and transmits to the user at user terminal 300. This language conditional offers submitted from a single buyer, 

describes the legal implications of offering the guaranteed Next, at step 746, central controller 200 receives either a 

purchase offer, and the process is similar to reviewing terms 5 request to accept a particular offer, or a request to review 

before signing a written contract. If the user elects not to offers for other events. In the latter case, steps 740, 742 and 

abide by these terms, he may cancel the offer. However, if 746 will be repeated. It should be noted that the user may 

the user does elect to abide by the terms, the user transmits exit the system at any time prior to accepting an offer, 

a positive acknowledgment to central controller 200, and is After the user transmits a request to accept a particular 

legally bound to the terms of the guaranteed purchase offer. 10 offer, at step 748 the user transmits the original ticket 

In FIG. 7c, central controller 200 then contacts the user's number and seat location (i.e. section, row and seat) to 
credit card issuer at step 732 to receive authorization for the central controller 200. Upon receiving this information from 
offer First, central controller 200 collects the user name, the user, central controller 200 at step 750 transmits the 
address, credit card type, credit card number, and expiration ]5 original ticket number and seat location to the venue con- 
date from customer table 530, based on the customer ID troller 400 for verification of the ticket's validity, 
from the offer table 550. This information along with the Referring now to FIG. le, at step 752 venue controller 400 
authorization amount from field 566 of the offer table 550 is retrieves a record from ticket table 610 matching the ticket 
transmitted to the credit card issuer through credit card number transmitted by central controller 200 in step 750. 
processor 230. 20 Venue controller 400 verifies that the transmitted ticket 

At step 734, the central controller 200 receives either an number matches the transmitted seat location at steps 754 

authorization or rejection from the credit card issuer through and 756. If the transmitted ticket and seat location do not 

credit card processor 230. The credit card issuer may reject match, at step 758, venue controller 400 transmits an invalid 

the request for any number of reasons, including an expired combination message to central controller 200. Central 

card, overextended credit limit, or delinquency in payments. 25 controller 200 then transmits a message to user terminal 300 

Upon rejection, at step 736 central controller 200 notifies the indicating that the ticket number and seat location are an 

user at user terminal 300 of this rejection and requests invalid combination at step 760. Upon receiving the invalid 

separate credit card information. Alternatively, the user may combination message at user terminal 300, the user can 

transmit information corresponding to a separate credit card, 3Q resubmit the ticket and seat location to central controller 200 

which supplements or replaces his present information in the at step 770. The process then loops back to step 750. If the 

customer table 530. If alternative credit card information is ticket number and seat location combination is valid, the 

provided, step 732 is repeated in order to receive authori- process continues with step 772. 

zation for the charge. Upon receiving authorization from the At step 772 of FIG. 7/, central controller 200 transmits to 

credit card issuer through the credit card processor 230, 35 user terminal 300 legal contract language which is displayed 

central controller 200 updates offer table 520, including to the user selling his ticket. As previously indicated, this 

changing status field 557 to "active" to confirm the posted contract language may be stored in a contract detail table 

offer. (not shown). This language describes the legal implications 

FIGS. Id-lg illustrate the processing steps executed ^ of accepting the guaranteed purchase offer, and the process 

based on the user's choice at step 714 to review offers from is similar to reviewing terms before signing a written 

potential buyers. At step 740, central controller 200 trans- contract. If the user selling his ticket elects not to abide by 

mits general venue and event information to user terminal these terms, the user may cancel his acceptance. However, 

300 for display to the user. As discussed earlier at step 716, if the user elects to abide by the terms, the user transmits a 

central controller 200 may provide a number of options to 45 positive acknowledgment to central controller 200, and is 

the user to identify the exact event the user wishes to review. legally bound to the acceptance. 

Ultimately, central controller 200 provides the user with the Central controller 200 then contacts the user's credit card 

event ID from field 502 of the event table 500. At step 742, issuer at step 776 to receive authorization for the acceptance, 

the user supplies the event ID to central controller 200 so it Central controller 200 requests authorization from the credit 

may identify associated offers in offer table 550. card issuer to reserve a portion of the user's credit based on 

At step 744, central controller 200 identifies offer records the offer information and credit information collected from 

associated with the selected event ID and having an "active" the user at step 706 and stored in customer table 530. This 

status. Central controller 200 transmits this data to user credit reservation is a fraud deterrent and may be used as a 

terminal 300 for display to the user. The user may review all 55 penalty in the event the seller fails to deliver the tickets, 

offers for the specific event together, or one at a time. In one Such a penalty creates buyer confidence and provides assur- 

embodiment, the user may review each individual offer ance to a user buying the ticket that the user selling the ticket 

through a graphic display of the venue, to pinpoint exactly will, in fact, relinquish the tickets. The penalty could be paid 

where the buyer is requesting seats. In some cases, the offer to the user buying the ticket if the user selling the ticket 

may be for seats anywhere in the entire arena. In others, the 60 attempts to repudiate the agreement. This penalty may be 

offer may only be for a specific range of sections, rows or determined in a number of ways including imposing a flat 

seats. In one embodiment, the user may be able to enter their penalty on the user selling the ticket or imposing a penalty 

exact ticket information to confirm whether it meets the equal to the entire amount offered by the user buying the 

requirements of the offer. 65 ticket. 

As previously discussed, linked offers will be appropri- At step 774, central controller 200 collects information 

ately identified upon presentation to the user. In this case, from the user selling the ticket. The information may include 
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the user name, address, credit card number and expiration 
date from customer table 530, based on the customer ID 
retrieved from the offer table 550. This information, along 
with the authorization amount from field 566 of the offer 
table 550, is transmitted to the credit card issuer through 
credit card processor 230. 

At step 776, central controller 200 receives either an 
authorization or rejection from the credit card issuer through 
credit card processor 230. The credit card issuer may reject 
the request for any number of reasons, including an expired 
card, overextended credit limit, or delinquency in payments. 
Upon rejection, at step 728 central controller 200 notifies the 
user at user terminal 300 of the rejection and requests 
alternate credit card information. The user may attempt to 
transmit the same credit information as provided earlier, 
because the user may have mistakenly transmitted incorrect 
information earlier. Alternatively, the user may transmit 
information corresponding to an alternate credit card, which 
will supplement or replace the credit card information in 
customer table 530. Further, the user could cancel the 
transaction altogether. If alternative credit card information 
is provided, step 774 is repeated in order to receive autho- 
rization for the charge. 

If central controller 200 receives authorization from the 
credit card issuer through credit card processor 230, the 
process continues with step 780 wherein central controller 
200 generates and assigns a transaction ID to the sale. This 
transaction ID is stored in field 567 of the offer table 550. 
Further, central controller 200 creates a new record in 
transaction table 580, indexed by the assigned transaction 
ID. The assigned transaction ID is also stored in field 581 of 
transaction table 580. The original ticket number 590 field of 
transaction table 580 is populated with the appropriate ticket 
number(s) from the user selling the ticket. Further, central 
controller 200 timestamps the acceptance using date field 
583 indicating when the acceptance was posted. 

Once the guaranteed purchase offer has been accepted, 
central controller 200 uses the customer ID from field 552 as 
an index into customer table 530 to retrieve the name of the 
user buying the ticket. At step 782, central controller 200 
transmits the name of user buying the ticket to the venue 
controller 400. 

At step 784, venue controller 400 creates a new record in 
replacement ticket table 630. The new record is populated 
with information indicating the buyer's name, the original 
ticket number, the section, row and seat of the ticket. As 
shown at step 786, the new record is further populated with 
a replacement ticket number assigned by venue controller 
400. The replacement ticket number is then transmitted to 
central controller 200 

Once central controller 200 has received the replacement 
ticket number 642 from venue controller 400, central con- 
troller 200 then updates the new ticket number field 594 of 
transaction table 580 at step 788. At step 790, central 
controller 200 determines the payment due and charges the 
credit card, of the user buying the ticket, the price of the 
ticket plus a processing fee 587. Central controller 200 also 
updates field 585 of the transaction table 580 with the 
amount charged. Finally, central controller 200 updates field 
589 with the seller ID of the user accepting the offer, and 
central controller 200 updates field 586 with the seller 
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amount authorized in the event that the seller tries to use his 
sold ticket. Field 584 is updated based on buyer amount 
charged 585 less the processing fee 587. Although fees of the 
present embodiment are illustrated as being stored in a table, 
5 such fees could easily be calculated instead of being 
retrieved from a table. 

At step 792, central controller 200 transmits a message to 
user terminal 300 to notify the user selling the ticket that it 

j 0 will credit his credit card account with the sale amount of the 
ticket as soon as central controller 200 receives verification 
that the original tickets have been surrendered. 

At step 794 the central controller transmits replacement 
ticket number 692 and a message to the user buying the 

15 ticket indicating that his guaranteed offer has been accepted. 
The user buying the ticket may then print the replacement 
ticket number, take it to the venue and use it to gain access 
to the desired event, at step 796. The cancellation of the 

20 original number and issuance of a replacement ticket num- 
ber tied to the purchasing user's name is done in order to 
prevent fraud by either the ticket seller and/or the purchaser. 

For instance, if a seller arrives at a venue with a ticket, and 
. a purchaser also arrives to the same venue with a replace- 

25 ment ticket for the same seat, the venue controller can be 
accessed to determine which ticket is valid. The replacement 
ticket always supersedes the original ticket, provided it is 
registered in the replacement ticket table 630 of the venue 

3Q controller 400. If such fraud is attempted by the seller and 
detected by central controller 200, the central controller can 
charge the seller's credit card account the seller amount 
authorized in field 856 of transaction table 580. 
As another example, if two people arrive at the venue with 

35 the same replacement ticket, the venue controller can be 
accessed to determine the rightful owner, based on the 
contents of the new buyer name field 640, of replacement 
ticket table 630. These measures taken against fraud will 

4Q assure customers that there will be no problems in using 
central controller 200 to buy and sell tickets. 

Finally, at step 798, central controller 200 receives veri- 
fication that the original ticket has been received from the 
seller, and credits the credit card account of the user selling 

45 the ticket with the transaction amount 584. Central control- 
ler further updates the date tickets received field 588 accord- 
ingly. Surrender of the ticket is preferably accomplished by 
delivery of the ticket to a will call window of the venue, 
however other surrender arrangements are possible, such as 
through the postal service or Federal Express. Once the 
ticket has been surrendered and the transaction is complete, 
central controller 200 updates status field 557 of the offer 
table 550 to "completed" for tracking purposes. Upon 

55 receipt of the surrendered tickets, central controller 200 
credits the account of the user selling the tickets. 

Although the preferred method of surrendering the origi- 
nal tickets is using the mail or other delivery mechanism, 
numerous alternate embodiments are possible. Using one 

60 alternate embodiment, ticket redemption could be construc- 
tively accomplished at the time an offer to buy is irrevocably 
accepted, The alternate embodiment employs event tickets 
that can be physically altered to render them invalid or void. 

6 5 Each ticket includes a unique ticket number that is pre- 
printed on the face of the ticket, but obscured from view by 
a scratch-off covering, such as an opaque latex coating. The 
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ticket number is unknown to the ticket holder unless the 
scratch -off covering is removed. 

At the time of acceptance, the seller possessing the tickets 
is instructed to remove the covering over the ticket number 
on each ticket to be sold. The ticket number is provided to 
central controller 200 to verify that the ticket seller is, in 
fact, in possession of valid tickets. The ticket number 
provided for each ticket involved in the transaction is then 
electronically voided and replacement ticket number is 
assigned as previously described. 

The act of revealing the ticket number not only serves to 
verify the ticket seller's possession of the tickets, but also 
eliminates the need for the seller to surrender the tickets 
because removal of the scratch-off covering voids the tick- 
ets. While this alternate embodiment requires additional 
structure with respect to the event tickets, it eliminates the 
need to reserve a portion of the seller's credit line as a 
penalty for failing to return the unused tickets. 
Illustrative Example 

An illustrative example of the invention will now be 
described using the data populating various fields of the 
figures. Record 572 of the offer table 550 is a guaranteed 
offer to buy as indicated by type field 556 that has been 
submitted by user 4000 as identified by customer ID field 
552, User 4000, as denoted by record 548 in the customer 
table 530 is Sue Black, residing at 101 Pink Ave in Norwalk, 
CT. The credit card number submitted to central controller 
200 is Discover card number 4444-4444-4444-4444 that 
expires August 2002 and was issued to Susan Black. 

In record 572 of the offer table 550, Sue Black has posted 
a guaranteed offer to buy two tickets to event ID E001, as 
denoted by event ID field 553, for $200.00 per ticket in the 
first row of the first section of the venue. As denoted by 
record 514 of event table 500, event E001 is an NHL game, 
specifically NJ Devils vs. New York Rangers, occurring on 
5/6/97 at 7:30 PM at "MSG" as denoted by venue ID field 
508, Record 526 of venue table 520 identifies MSG as the 
Madison Square Garden venue in New York, N.Y 

In addition to this guaranteed purchase offer, Sue Black 
has also posted a link offer as denoted by linked ID field 568. 
This linked offer has an ID code of 0333. Record 570 of offer 
table 550 has the offer ID 0333, and is therefore the offer that 
is linked to record 572. Record 570 is an offer by Sue Black 
to purchase four tickets to the NHL game NJ Devils vs. New 
York Rangers having the same date and time as the offer 
request of record 572. In record 570, Sue Black indicates 
that she will pay $250 each for four tickets in the first row 
of the first section of the venue. Because offer 570 is linked 
to offer 572, Sue Black has indicated that she would like one 
or the other of the two offers. 

Field 566 of offer table 550 indicates that $1,000 has been 
authorized by Discover for account 4444-4444-4444-4444 
for both records 570 and 572, submitted by Sue Black. 
$1,000 is the maximum possible amount that Sue Black's 
offers could cost her if one of them is fulfilled. 

For record 572, the transaction ID field 567 has been 
populated with a transaction ID, indicating that a buyer has 
accepted Sue Black's guaranteed offer to buy. Status field 
557 of record 572 registers that the offer has been fulfilled, 
and the status record 570 is expired, since it was linked to 
record 572 in a way indicating that if one was filled, the 
other should be disregarded. 



40,396 Bl 

16 

Record 595 of transaction table 580 describes the detail of 
transaction TR001, which is the acceptance of Sue Black's 
guaranteed offer to buy by seller 2000, as indicated by seller 
ID field 589. 

5 Record 570 of the customer table 530 indicates that 
customer having the ID number 2000, as indicated by 
customer ID field 532, is Jill Janson, residing in 456 Red 
Drive, Atlanta GA, and having Master Card number 2222- 
2222-2222-2222 with expiration date 9/99 registered with 

10 central controller 200. 

Record 595 indicates that Sue Black was charged $420 on 
5/2/97 for her purchase of seats 003 and 004 of row 1, seat 
1 of the event tied to the record of her guaranteed purchase 

15 offer in offer table 550. Record 595 also indicates that Jill 
Janson has sold her original ticket numbers 667913 and 
667914, stored in the original ticket number field 810, for 
section 001, row 001, and seat 003 and 004. The seller 
amount authorized field 585 stores $400, the amount that 

20 central controller 200 has been authorized by Mastercard to 
debit from account 2222-2222-2222-2222 in the event that 
Jill Janson does not honor her agreement to sell her tickets. 
All or a portion of this amount can be credited to Sue Black 
if there is a problem using her new ticket number for access 

25 to the venue event. 

The date tickets received field 588 is blank for this record, 
indicating that central controller 200 has not yet received 
verification that Jill Janson has surrendered her tickets. Once 

3Q central controller 200 has received verification that Jill 
Janson has surrendered her tickets, Jill Janson's credit card 
account will be credited $380, the amount stored in trans- 
action amount field 584. 
Central controller 200 has issued replacement ticket num- 

35 bers to Sue Black for both seats. These replacement ticket 
numbers are stored in field 594. Preferably, Sue Black will 
print out these replacement ticket numbers and take them 
with her to the venue to gain access to the event. 
Records 622 and 624 of ticket table 610 store information 

40 

relating to the original tickets issued to Jill Janson. Records 
644 and 646 of replacement ticket table 630 store the 
replacement ticket numbers issued by central controller 200 
to Sue Black, which replace the original ticket numbers 
45 given to Jill Janson. These records are stored by venue 
controller 400 to be used in the event of fraud as previously 
described. 

It is important to note that in the embodiment described 
above, the notification of the parties, both buyer and seller 
is performed through contacting their respective remote user 
terminals. This notification can also be performed using 
conventional technology including but not limited to 
telephone, facsimile, e-mail and paging. 

55 In addition to the guaranteed offer and acceptance system 
of the present invention, the present embodiment is also well 
suited for other aspects of ticket resale. For example, the 
present embodiment can include a registration process for 
certain events or tickets. Such a process would enable a 

60 prospective ticket buyer to set up a ticket watch which could 
be implemented by central controller 200. Central controller 
200 could periodically poll offers to determine if specific 
tickets are available. Availability could be transmitted to a 

65 user via conventional telephone lines, E-mail, facsimile or 
pager. A notification preference could be determined by the 
user during the registration process. 
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Another aspect of ticket resale that is well suited to the 
present embodiment is advertising. Instead of simply allow- 
ing users to place, review and accept offers, the system could 
provide advertising for products related to events and tick- 
ets. 

Of course, these and many other features and advantages 
of the present invention are apparent from the detailed 
specification. Thus, it is intended by the appended claims to 
cover all such features and advantages of the invention 
which fall within the true spirit and scope of the present 
invention. 

Furthermore, since numerous modifications and varia- 
tions will readily occur to those skilled in the art, it is not 
desired that the present invention be limited to the exact 
construction and operation illustrated and described herein, 
and accordingly, all suitable modifications and equivalents 
which may be resorted to are intended to fall within the 
scope of the claims. 

We claim: 

1. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer; and 

electronically receiving a second general purpose finan- 
cial account number from said seller and authorization 
to charge an account identified by said second general 
purpose account number; and processing a charge 
applied to said account. 

2. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 50 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; 

electronically receiving a signal representing a ticket 
number associated with said event ticket and process- 
ing a payment to said seller; and 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer. 

3. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
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account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 
electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer; and 

electronically storing data representing a cancellation of 
said event ticket. 

4. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

receiving name data representing an identity of said 
buyer; 

storing said name data to associate said identity of said 
buyer with said event ticket; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; and 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer. 

5. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer, 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer; and 

transmitting to a venue controller a ticket identifier asso- 
ciated with said event ticket. 

6. The method of claim 5, wherein the step of determining 
said replacement ticket identifier includes the step of receiv- 
ing said replacement ticket identifier from said venue con- 
troller. 

7. A method for electronically completing a transaction 
between a remote prospective event ticket buyer and a 
remote potential event ticket seller, comprising: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least one condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 
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electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; and 5 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer, wherein 
said replacement ticket number includes an original 
ticket identifier. 

1 n 

8. A computer- readable storage medium encoded with 
processing instructions for implementing a method for elec- 
tronically completing a transaction between a remote pro- 
spective event ticket buyer and a remote potential event 
ticket seller, said processing instructions for directing a ^ 
computer to perform the steps of: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least on condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 20 
pose financial account for a purchase meeting said at 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer, 30 

electronically receiving a second general purpose finan- 
cial account number from said seller and authorization 
to charge an account identified by said second general 
purpose account number; and 

processing a charge applied to said account. 35 

9. A computer- readable storage medium encoded with 
processing instructions for implementing a method for elec- 
tronically completing a transaction between a remote pro- 
spective event ticket buyer and a remote potential event ^ 
ticket seller, said processing instructions for directing a 
computer to perform the steps of: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least on condition, an 
account number from a general purpose financial 45 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

receiving name data representing an identity of said 
buyer; storing said name data to associate said identity 50 
of said buyer with said event ticket; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 55 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; and 
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electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer. 

10. A computer-readable storage medium encoded with 

processing instructions for implementing a method for elec- 
tronically completing a transaction between a remote pro- 
spective event ticket buyer and a remote potential event 
ticket seller, said processing instructions for directing a 
computer to perform the steps of: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least on condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer, and 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer; and 

transmitting to a venue controller a ticket identifier asso- 
ciated with said event ticket. 

11. The article of manufacture of claim 10 wherein the 
step of determining said replacement ticket identifier 
includes the step of receiving said replacement ticket iden- 
tifier from said venue controller. t 

12. A computer-readable storage medium encoded with 
processing instructions for implementing a method for elec- 
tronically completing a transaction between a remote pro- 
spective event ticket buyer and a remote potential event 
ticket seller, said processing instructions for directing a 
computer to perform the steps of: 

electronically receiving from said buyer a purchase offer 
for an event ticket containing at least on condition, an 
account number from a general purpose financial 
account, and authorization to charge said general pur- 
pose financial account for a purchase meeting said at 
least one condition; 

electronically making available said purchase offer to a 
plurality of remote potential event ticket sellers; 

electronically receiving from at least one of said remote 
potential event ticket sellers an unconditional accep- 
tance of said purchase offer; and 

electronically transmitting a replacement ticket number 
associated with said event ticket to said buyer, 

wherein said replacement ticket number includes an origi- 
nal ticket identifier, 

* * * % * 
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An improved multiple order facility for a computerized 
trading system in which a first trader submits a plurality of 
orders for display and acceptance by other traders, including 
a first subsystem which permits the first trader to simulta- 
neously generate a plurality of orders, and a second sub- 
system which displays the orders at computer terminals of 
the other traders to whom the orders were sent. Using the 
first subsystem, the first trader selects one or more financial 
instruments associated with a respective one of the orders 
from a displayed list of related financial instruments, selects 
a common quantity to be applied to each of the orders, and 
selects, for each order, a respective price at which the first 
trader is willing to buy or sell the financial instrument 
associated with that order. Each of the orders is then sent to 
a plurality of other trading using the computerized trading 
system. The second subsystem provides a display of the 
orders at computer terminals for each of the other traders to 
whom the orders were sent. Each order display includes the 
price for the financial instrument associated with the order as 
selected by the first trader; and an available quantity of the 
financial instrument associated with the order, the available 
quantity initially being equal to the common quantity set by 
the first trader and being reduced whenever a deal is made 
covering only a part of any of the plurality of orders by any 
of the other traders. 
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COMBINED ORDER LIMIT FOR A GROUP 
OF RELATED TRANSACTIONS IN AN 
AUTOMATED DEALING SYSTEM 

CROSS REFERENCE TO RELATED 

APPLICATION 5 

This application is based on and claims the benefit under 
35 U.S.C. 119 of U.S. Provisional US Application No, 
60/099,243 filed on Sep. 4, 1998, which is hereby incorpo- 
rated by reference in its entirety. 

TECHNICAL FIELD 10 

The present invention relates generally to an electronic 
brokerage system having a communication network con- 
necting traders dealing in financial instruments, and more 
particularly to a computerized system for coordinated trad- 15 
ing of multiple instruments such as different tenors of 
forward rate agreements for the same currency. 

Commonly assigned U.S. Pat. No. 5,375,055 (Togher et 
al) discloses an automated matching system for anonymous 
trading of foreign currencies in which traders may enter bids 2 q 
and offers through trader workstations into a distributed 
matching system. Credit limits, set by the potential parties to 
a transaction, are stored at Market Access Nodes to which 
the workstations are connected. The credit limits are ana- 
lyzed as part of the deal completion procedure, and deals 
which would exceed the credit limits are inhibited. The 25 
Market Access Nodes are finked to one or more Arbitrators 
and to one or more Market Distributors. The Market Dis- 
tributors' function is to distribute prices of open bids and 
offers using a Pre-Authorization Matrix derived from credit 
limits stored at the Market Access Nodes. The Pre- 30 
Authorization Matrix is used to inhibit trades between 
incompatible counterparties and also to screen bids/offers 
prior to display so that bids/offers shown to a trader are 
"dealable", that is, there is credit available to the trader to at 
least partially deal the displayed quote. An improved version 35 
of this system is also known and implemented as the EBS 
system for anonymous dealing of spot foreign exchange 
transactions. 

The known EBS system also includes a provision for 
establishing minimum and maximum amounts for any single 40 
trade by a particular trader and for establishing a default 
price (based on current market conditions) and amount 
(based on trader preference) for a single proposed trade 
which the trader can adjust upwards or downwards before 
submitting to the market for possible acceptance of other 45 
traders with whom he has bidirectional credit. 

We have appreciated, however, that while many aspects of 
such a spot trading system are also applicable to the trading 
of derivatives, the derivatives market is more segmented in 
terms of the particular "tenors" being traded for a particular 50 
currency or other commodity, and as a result, a trader will 
frequently want to enter alternative proposals for a particular 
commodity, differing only by settlement date, gap, or other 
settlement terms. However, because of the fast response 
times inherent in an automated trading system, it is not 55 
feasible for a trader to enter the alternate proposals into the 
known trading system as separate orders without risking 
more than one such order offer being accepted before the 
remaining orders can be manually canceled. The situation is 
further exacerbated if only part of an outstanding order is 60 
accepted and/or if different orders have different associated 
risks or limits, so that more is required than simply canceling 
one order if an alternate related order is accepted. 

SUMMARY OF THE INVENTION 65 

Accordingly, there is provided an improved computerized 
trading system for trading financial instruments or other 
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commodities between traders at trader terminals, wherein 
the trading system facilitates manual entry and possible 
revision of a group of related orders for derivatives based on 
a common underlying currency or other commodity. In 
particular, the group of orders may optionally be made be 
subject to a common order limit whereby all the related 
orders are automatically reduced whenever one such order is 
accepted. This gives a degree of control and flexibility not 
provided in the prior art noted above, providing greater 
market liquidity and flexibility of terms to potential market 
participants without appreciably increasing the potential 
exposure assumed by the market maker responsible for the 
multiple orders. 

In one embodiment, the group of related orders are 
selected from a respective "sheet" of different "tenors" for 
forward rate agreements in the same side of the market and 
involving the same currency, the same gap, and the same 
reference rate. However, without departing from the spirit of 
the present invention, several such groups may combined 
under a single order limit, and/or the same or a combination 
of such groups may be subject to multiple, possibly over- 
lapping credit limits. 

In another embodiment, the sizes of the different tenors 
subject to a combined order limit are normalized in accor- 
dance with defined differences between the different tenors 
of the same group, such as gap or minimum deal size 
(notional amount), conventionally associated with each indi- 
vidual tenor. 

Preferably, the available amount associated with a par- 
ticular order limit is initially set above a predetermined 
minimum notional amount applicable to all the selected 
tenors in the associated group, regardless of exposure, and is 
automatically adjusted as the individual orders for those 
particular tenors are matched, completed, or re-entered. As 
each such adjustment to the available amount is made, the 
notional amounts for all of the other individual open orders 
subject to that same order limit are also compared with the 
adjusted available amount, possibly taking into account not 
only the actual notional amounts involved but also the 
relative exposure associated with each tenor and/or other 
market conventions used to "normalize" the minimum 
notional amounts frequently associated with different tenors, 
such as a "3-month equivalenf \ 

It should be noted that the embodiment described later is 
one in which the functions of the network are distributed 
throughout a variety of components. This is considered to be 
the most effective manner of implementing the system. 
However, it will be appreciated that it would possible to 
incorporate this functionality into a system with a single 
location for alt these functions, or into another system 
architecture having some aspects of a fully distributed 
system and some aspects of a fully centralized system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

An embodiment of the invention will be described by way 
of example only, and with reference to the accompanying 
figures in which: 

FIG. 1 depicts an overview of the trader's trading screen; 

FIG. 2 shows a Tenor Detail Panel for the trader's screen 
shown in FIG. 1; 

FIG. 3 shows Order Request Panel for the trader's screen 
shown in FIG. 1; 

FIG. 4 shows a Multiple Order Request Panel for the 
trader's screen shown in FIG. 1; 

FIG. 5 shows an exemplary system architecture based on 
an existing EBS system. 
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DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The system of the present invention is applicable to 
trading various types of derivatives contracts but is 
described in relation to Forward Rate Agreements (FRA) for 5 
which the described embodiment has been especially 
adapted. 

Overview of FRA's 

A Forward Rate Agreement (FRA) is a contract between 
two parties to lock in a forward interest rate, for a period, 10 
starting at a specific date in the future. Each FRA contract 
can be categorized as a spot FRA, an IMM FRA, or a broken 
date FRA. All these may be traded on the system of the 
present embodiment. IMM is the abbreviation which has 
become customary to refer to an instrument traded on one of 
the International Monetary Market dates. In brief, IMM 
FRAs are traded for the four International Monetary Market 
(IMM) dates. Spot FRAs are traded for dates associated with 
today's spot date. A broken date FRA is a spot FRA which 
is traded for a different spot date than today's spot date. 

A FRA trading screen of a system embodying the inven- 20 
tion is shown in FIG. 1. The FRA trading workstation 
presents a set of FRA contracts that may be traded in an 
electronically brokered format. Each type of contract is 
known as a tenor. Price information for a particular tenor is 
displayed on a tenor line. For each tenor line, the dealing 25 
system presents the best credit-screened bid and offer prices 
of all active quotes. Upon selection of the tenor line, the 
workstation presents a detailed view of the associated tenor 
showing contract dates and additional market view infor- 
mation. 30 

A trader may select a tenor line and then submit one of 
four order types (Bid, Offer, Buy, or Sell). Each type of order 
requires the trader to specify an interest rate notional amount 
for a particular tenor. Once submitted, new orders are 
matched with outstanding orders in price/time priority. 35 
Compatible orders are matched resulting in the execution of 
deals. In order to encourage market making a trader can 
submit and adjust bids and offers for several tenors at a time. 

For non-standard FRAs, a price inquiry function allows 
the trader to issue a system -wide broadcast to request a price 



For example, a 6x9 FRA is a contract covering a period 
that begins 6 months from now and ends 9 months from now. 
The term or gap of such a contract is 3 months. The two 
counterparties, one buyer and one seller, settle by cash 
payment at the start of the contract (in this case 6 months 
from now). 

The buyer of a FRA will be compensated if future interest 
rates rise. The seller of an FRA will be compensated if future 
interest rates fall. 

Settlement is based on the difference between the actual 
interest rate prevailing on the fixing date and the rate 
specified in the contract, for a specific notional amount 
stated in the contract. Settlement takes place at the beginning 
of the term. 

As an example, consider a USD 6x9 FRA trade for $100 
million (US) at an agreed upon rate of 5.5675 executed on 
Sept. 9, 1997. The deal has the following characteristics: 

Trade Date: Sep. 9, 1997 

Spot Date: Sep. 11, 1997 

Fixing Date: Mar. 9, 1998 

Settlement Date: Mar. 11, 1998 

Maturity Date: Jun. 11, 1998 

Contract Rate: 5.5675 

Notional Amount: 100 million (US$) 

Reference Rate: LIBOR 

The period of this deal begins on Mar. 11, 1998 (the 
settlement date) and ends on Jun. 11, 1998 (the maturity 
date). On March 9 th , sometime after 11:30 AM London time, 
the back office personnel at each bank will look on the 
appropriate Reuters page to read the 3-month LIBOR rate 
posted for March 9 th . If, for example, this rate is 5.5800 (the 
"Fixing Rate") then between the Trade Date and the Settle- 
ment Date, the interest rate has risen 0.0125 percent or IV* 
basis points. Therefore, a settlement amount must be calcu- 
lated based on this Fixing Rate of 5.58%. The settlement 
amount is the amount on the check paid by the seller to the 
buyer. The settlement amount is calculated using the fol- 
lowing formula: 



( (Fixing Rate ) - (Contract Rate ) ^ / Days in Period "\ t 

[ 100 )\ 360 J -(Notional Amount 



( Fixing Rate 

1+ l — loo — 



)( 



Days in Period \ 



360 
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for a broken date FRA. A trader may respond to a price 
inquiry by selecting the entry in the bulletin board. 50 

The trading screen shown in FIG. 1 provides traders with 
the facility to enter bids, offers, buy or sell orders by 
selecting buttons on a toolbar at the top of the screen. The 
best bid/offer prices are displayed for tenors of various lines 
in one window and deals done by the trader and on the 55 
system as a whole are displayed in other windows. The 
display is better understood with reference to an example of 
a FRA deal. 

If a single tenor is selected (for example, by means of a 
mouse or keypad at the trader's workstation), then the details 
of the FRA tenor line are presented in the top section of the 60 
screen. The detail area shows the best dealable, EBS best, 
and best regular prices for the selected tenor. The fixing date, 
settlement date, and maturity date of the active tenor are 
shown as well. 

As explained, a Forward Rate Agreement (FRA) is a 65 
contract between two parties to lock in a forward interest 
rate, for a period, starting at a specific date in the future. 
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which reduces to: 



3194.44 
1.01426 



= 3149.53 



with the denominator (1.01426) merely being a "present 
value" discount which takes into account the fact that 
although the quoted rate assumes payment of principal 
and interest at the end of the Period in question, 
settlement actually occurs at the beginning. Note that if 
interest rates had fallen, then the buyer of the FRA must 
pay the seller the settlement amount. 
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FRAs serve as both a hedging and a speculative instru- 
ment. A bank may use an FRA to hedge against future 
inflows and outflows of cash on its balance sheet, or a bank 
may use an FRA to speculate in the future movement of 
interest rates. By definition, an FRA trades over-the-counter. 5 
The resultant contract is between two parties and is therefore 
dissimilar to a futures contract which is traded via an 
exchange. 

The foregoing embodiment is described in relation to 
IMM FRAs; that is FRAs which are based on the Interna- 10 
tional Monetary Market dates. However, many aspects of the 
present invention are also applicable to other types of FRAs 
such as Spot FRAs and Broken Date FRAs. 

FRAs are distinguished by the dates of the contract, the 15 
reference rate, and the contract currency. Each type of FRA 
contract is called a tenor. Some example tenors are listed 
below: 



Examples of FRA Tenors: 


Cash 3 month 


Cash 6 month 


Cash 12 month 


USD 1x4 
USD 3x6 
JPY 6 x 9 


DEM 1x7 
USD 2x8 
JPY 6 x 12 


USD 1 x 13 
DEM 2 x 14 
USD 12 x 24 




IMM FRAs with 




IMM FRAs 


a 6 month gap 


Broken Date FRAs 


USD Sep 97 
USD Dec 97 
JPY Mar 98 


USD Jun 97-6 
USD Sep 98-6 
JPY Sep 98-6 


USD 3x6 (12) 
DEM 2 x 14 (10) 
USD 0 x 3 (3) 



25 



The "Reference Rate" specifies how the interest rate is 
determined to which the contract interest rate will be fixed 
in order to determine the settlement amount. A common 
Reference Rate is LIBOR that is an acronym for London 
Interbank Offered Rate. Other examples include PIBOR 
(Paris), TEBOR (Tokyo), PRIBOR (Prague), and DIBOR 
(Dublin). The settlement calculation will use the interest rate 
associated with the turn of the contract. For example, a USD 
1x4 FRA contract will have a three month LIBOR fixing. 
The daily set of LIBOR rates is the result of a survey of 
London banks and is made available on a Reuters page and 
later published in financial newspapers. The following list 
shows Reference Rates for common FRA tenors in various 
contract currencies. 



Currency Reference Rate 



USD LIBOR 

YEN LIBOR S5 

CHF LIBOR 

GBP LIBOR 

DEM LIBOR/FIBOR 

AUD LIBOR 

CAD LIBOR/CDOR 

FRF LIBOR/PIBOR 

XEU LIBOR 60 

ITL LIBOR 

ESP LIBOR 

PTE LIBOR/LISFRA 

NLO AIBOR 

SEK STIBOR 

DKK CIBOR 65 

NOK NIBOR 
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-continued 


Currency 


Reference Rate 


FIM 


HELIBOR 


BEF 


BIBOR 


NZD 


KIBOR 



An instrument refers to the class of trades or potential 
trades which would be settled under equivalent FRA terms. 
(This does not include FRABBA/ISDA terms) This classi- 
fication can be uniquely defined by the following criteria: 

Contract Currency 

Reference Rate 

Fixing Date 

Maturity Date 
Exemplary Trader's Workstation 

Turning again to FIG. 1, the screen can now be better 
understood. The Tenor Detail Panel (TDP) provides a 
detailed view of tenor line information and transaction 
activity for a single tenor. The Tab Controls (TC)(only one 
is shown in FIG. 1) allow a user to select one of several 
user-defined tab sheets. The user may designate the tab sheet 
properties and components. Although for the sake of clarity 
only a single tab sheet is shown, in a typical usage 
environment, a trader may have multiple tabs sheets, each 
associated with a different combination of currency and 
reference rate. It would also be possible to include more than 
one combination of currency and Reference Rate on the 
same sheet, thereby facilitating the creation of a single credit 
limit for two or more instruments which are normally not 
considered related. Each individual Tenor Line (TL) shows 
a tenor indicator (e.g., September 1998 IMM FRA for USD), 
best bid and offer prices, best amount available for bid and 
offer and a big figure. 

A number of tenor lines (more than fifty) may be visible 
on the screen concurrently. There may be additional tenor 
lines that are not visible on the screen due to space con- 
straints (identified with an appropriate Tab (T)), but can be 
easily brought into view. The screen also allows the trader to 
elect to show fewer tenors (as few as eight) depending upon 
the trader's preference. 

The Tenor Detail Panel (TDP) is shown in FIG. 2 and 
shows a selected Tenor Line in more detail. It includes: 

Tenor Identification (TT) (currency and description) 

Tenor Date Information (TDI) (Fixing Date, Settlement 
Date, and Maturity Date) 

Regular Dealable Bid (RDB) and Offer (RDO) Prices for 
"regular" amounts satisfying credit screening (A "regu- 
lar" amount is an amount at least equal to a system 
default value representative of a typical trade in a 
particular currency, and may for example be 50 M 
pounds) 

Best Dealable Bid (BDB) and Offer (BDO) Prices (the 
best price available after credit screening for any 
amount) along with the total quantity ("Best Bid and 
Offer Amounts") available at those prices. EBS Best 
Bid (BBP) and Offer (BO) Prices (the best price avail- 
able on the whole system regardless of credit (even this 
may not be available to the trader) if this different from 
the corresponding Best Dealable Prices. Note that 
much of this information is also shown in each Tenor 
Line of each Tab Sheet (TS) (FIG. 1). 
To the left of FIG. 2 is a bid/buy Order Status (OAOR) 
indicator showing the amount requested (50) and obtained 
(0) for an open order. If a Offer/Sell order was pending, its 
status would be displayed on the right. 
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Note that the bid (buy) prices are on the left hand side of 
the Tenor Detail Panel (TOP), and the offer (sell) prices are 
on the right hand side, and that all displayed prices are 
arranged in ascending order from left to right. The EBS Best 
Bid Price (BBP) (if shown) will always be better than the 
Best Dealable Bid (BDB) Price. This is because the credit 
granting entity for this trading floor may not have extended 
sufficient credit to the counterparty offering the Best Bid 
Price (or vice versa). Similarly, the Best Dealable Bid Price 



8 



will prevent the user from proceeding in case there a serious 
error condition is encountered, otherwise a warning is dis- 
played. The workstation will display the message as set forth 
in Table 1 (below) and will highlight the data field in red 
color. Each order is validated by the system prior to sub- 
mission to the market, and the trader is notified if any of the 
potential error conditions set forth in Table 1 are present: 



TABLE 1 



Deal Verification 



Buy/Sell Warning Name: 


Priority: 


Warning 
Type: 


Bid/Offei Warning Name: 


Priority: 


Warning 
Type: 


Price Can't Be Blank 


1 


Error 


Price Can't Be Blank 


1 


Error 


Trade Size Can't Be Blank 


2 


Error 


Trade Size Can't Be Blank 


2 


Error 


Trade Size Can't Be Zero 


3 


Error 


Trade Size Can't Be Zero 


3 


Error 


Price Can't Be Zero 


4 


Error 


Price Can't Be Zero 


4 


Error 


Price Not A Multiple of X 


5 


Error 


Price Not A Multiple of X 


5 


Error 


(Where X " Price Increment) 






(Where X = Price [ncrement) 






Trade Size Invalid 


8 


Error 


Price matches your own order 


6 


Error 


Trade Size > Max Trade Size 


9 


Error 


Trade Size Invalid 


7 


Error 


Check Fixing Date 


10 


Warning 


Trade Size > Max Trade Size 


8 


Error 


Large Difference 


11 


Warning 


Check Fixing Date 


9 


Warning 


Wide Spread 


12 


Warning 


Large Difference 


10 


Warning 


Check Rate 


13 


Warning 


Wide Spread 


11 


Warning 


Buy Up To? 


14 


Warning 


Check Rate 


12 


Warning 


Sell Down To? 


15 


Warning 


Big Figure Adjusted 


13 


Warning 


Check Price 


16 


Warning 








Big Figure Adjusted 


17 


Warning 









will always be at least as good as the Regular Dealable Bid 
(RDB) Price. In the particular example shown in FIG. 2, the 
Best Dealable Bid Amount is 120 which is larger than the 
"Regular" amount of 50, and consequently the same price 
(5.4775) is shown as the Regular Dealable Bid (RDB) Price 
and the Best Dealable Bid (BDB) Price. 

FIG. 3 shows the Offer Order Request Panel (ORP) which 
appears on the right side of the Tenor Detail Panel (TDP) 
when a particular Tenor has been selected and either the 
Offer Key (OK) or Sell (SK) Key (FIG. 1) has been 
activated. (A similar Bid Order Request Panel (not shown) 
appears on the left side of the Tenor Detail Panel when a 
particular Tenor has been selected and either the Bid or Buy 
key has been activated.) The Order Request Panel (ORP) 
includes an Amount Entry Field (AEF) and a Price Entry 
Field (PEF), both of which include Up (USB) and Down 
Spin Buttons (DSB) for adjusting the respect entries up or 
down, as well as a Send Pushbutton (SPB) for submitting the 
order (assuming appropriate validation checks are positive) 
and a Quit Pushbutton (QPB) which dismisses the Order 
Request Panel (ORP) without any action being taken. As 
previously indicated with respect to FIGS. 1 and 2, once a 
valid order has been submitted, its status is displayed on 
both the Tenor Detail Panel (TDP, FIG. 3) and in the 
corresponding Tenor Line (TL, FIG. 2), with the latter 
showing only the Amount Remaining (AR) in the outstand- 
ing order (i.e., the difference between the Amount Requested 
and the Amount Obtained shown in the Tenor Detail Panel). 
Validation 

The workstation will guard against user-input errors dur- 
ing order submission by providing a set of functions that 
validate against possible key-input errors. These validation 
functions may have the effect of preventing the user from 
entering an erroneous keystroke, preventing the user from 
submitting an order, or providing a warning to the user that 
an incorrect value may have been entered. The workstation 



35 



40 



45 



An exemplary set of applicable rules follows: 

1. The workstation will not allow a trader to submit more 
than one order on the same side of the market for a 
single tenor and will not allow submission of a single 
order for two or more tenors. 

2. A trader is allowed to cancel his outstanding order at 
anytime. 

3. The Buy and Offer orders are initiated at the Best 
Dealable Offer Price, unless the trader deliberately 
initiates a Buy at the Best Regular Offer price by 
clicking the Best Regular Offer price with the mouse or 
by pressing the buy reg key on the keypad. 

4. The Sell and Bid orders are initiated at the Best 
Dealable Bid Price, unless the trader deliberately ini- 
tiates a Sell at the Best Regular Bid price by clicking 
the Best Regular Bid price with the mouse or by 
pressing the sell reg key on the keypad. 

5. The workstation will not allow a bid/buy and offer/sell 
order to be submitted at the same time as it will not 
allow bid/buy and offer/sell panels to be open concur- 
rently. 

Submitting Multiple Orders 

Additionally, as shown in FIGS. 1 and 4, the trading 
workstation preferably provides many features for managing 
multiple orders as a group, whereby orders of similar type 
may be submitted for several tenors at a time. The user is 
able to select multiple tenors ("strip" or "group") using a 
mouse, keypad, or keyboard and then submit an order for all 
of the selected tenors with a valid price in one operation. If 
a single tenor holds Active Trading Focus (ATF) as shown 
in FIG. 1, the user is also able to click on a designated Select 
All (SA) button (FIG. 1) typically using a mouse or stylus 
65 (not shown) to select all (typically eight) tenors on the same 
Sheet (TS) and is able to submit an order for all of these 
tenors in one operation (the strip is highlighted and each 



50 



55 



60 
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tenor will contain a Selection Indicator e.g., a check mark). 
The workstation will send a separate order (Bid or Offer 
"quote" or Buy or Sell "hit") message to the banknode for 
each of the tenors selected. As in the case with submitting a 
single order, the workstation will present the notional 5 
amount for all of the orders such that the fields are editable 
using a mouse, keypad, or keyboard. 

After a group of orders has been selected, they may be 
interrupted (Tool Bar of FIG. 1), or modified and 
re-submitted as a group (using the Multiple -Order Request 10 
Panel (MORP) of FIG. 4). In this way, the trader is able to 
adjust a strip of outstanding orders as easily as adjusting a 
single order. 

In case of submission of multiple orders, the workstation 
will validate each order (as described above) and will 35 
highlight the order(s) that will have either an error or a 
warning condition (as described in the following sections). 
The workstation will prevent the submission of multiple 
orders as long as an error is encountered on a single order. 
Multiple Order Limit 20 

In accordance with an important aspect of the present 
invention, an optional Order Limit may be applied to a group 
of Multiple Orders involving different Tenors for the same 
Currency, with a separate Order Limit Notional Amount 
(OLNA) being established for Bids and Offers, 25 

A trader may designate a single amount that functions as 
a single limit amount for multiple orders for same currency. 
Typically, for each combination of currency (e.g., US 
Dollars) and reference rate (e.g. LIBOR), there is one Order 
Limit Amount (OLNA) for bids and buys, and another Order 30 
Limit Notional Amount (OLNA) for offers and sells. 

For a set of orders subject to an Order Limit any deal 
completed for one order under the Order Limit will reduce 
the size (that is, will reduce the notional amount) for all the 
orders by the deal amount. The reduced Order Notional 35 
Limit Amount will then become the available notional 
amount for every order submitted under the Order Limit. 

When the Order Limit Notional Amount (OLNA) falls 
below a trader or system defined Minimum Notional 
Amount (MNA) parameter, all orders subject to this Order 40 
Limit are removed by the dealing system. 

Both the Tenor Line (TL) and the Tenor Detail Panel (TP) 
of the workstation associated with the trader who has 
submitted an order to the market will display an Order Limit 
Enabled Indicator (OLEI) if an outstanding order from that 45 
trader is subject to an Order Limit imposed by that trader. 
The Tenor Line (TL) displays the Order Limit icon as an 
indicator and the amount of the outstanding order is initially 
set to the remaining Order Limit Amount. 

The Order Limit (also called safety net) panel is displayed 50 
at the bottom of each sheet for each currency (FIG. 4). The 
workstation will pre-fill the Order Limit Notional Amount 
with the default notional amount of the first tenor on that 
currency sheet (e.g., for the June 1998 USD IMM tenor), 
which then becomes the Order Size for each of the selected 55 
tenors once that particular Order Limit has been enabled. 
However, in an alternate embodiment (not shown), the Order 
Limit may be normalized to better take into account market 
recognized differences between tenors in the same group 
(for example, to take into account different gaps, using a 60 
three month equivalent notional amount). In that case the 
system generated Order Size may be greater than the nor- 
malized Order Limit for those tenors having a gap less than 
3 months, and may be less than the normalized Order Limit 
for those tenors having a gap greater than 3 months. 65 

Once the Multiple Order Panel (MORP) has been popu- 
lated with the default values for the Order Limit Notional 



Amount (OLNA) and the corresponding Order Size (OS) for 
each selected tenor (e.g., in FIG. 4 the order size 200 
(million) has been entered for each tenor of the four 
selected), it is advantageous for the trader to be able to adjust 
those default values, preferably by using a group Spin 
Button (SB) to adjust the Order Limit Amount and all the 
affected Order Sizes simultaneously, providing the trader is 
not attempting to define an illegal Order Limit Notional 
Amount for one of the selected tenors on his Multiple Order 
Panel (MORP) (for example, an amount that is not a 
multiple of the Notional Amount Increment or that is less 
than the Minimum Notional Amount for that currency). 

Once all the validations have taken place and before the 
individual orders are submitted to the market, the worksta- 
tion creates an Order Limit object and assigns a unique 
safety net ID to it. It will then send a message to the network 
node(s) responsible for enforcing the Order Limit Amount 
(typically the Arbitrator (ARB) bank's Market Access Node 
(FIG. 5, MAN) which cooperate to perform a initial match- 
ing process and two stage commit process with the coun- 
terparty's bank on each pending deal identified in the 
matching process before the deal is considered complete, as 
discussed in more detail hereinafter under the heading 
"Overview of Deal Matching Process/' 

The Safety Net ID may consist of the following fields: 

1 . Floor key - floor key of the banknode 

2. Session Number - session number of the trader session 
sent by the banknode 

3. Transaction Number - unique number to be assigned by 
the workstation 

4. Currency Key - identification of the currency involved 
Each safety net context will consist of four amounts: 

Safety Net Amount The original or total amount of the 
safety net. This value is set by the workstation and sent 
to the arbitrator. 

Dealt Amount The total amount of all completed deals 
made on quotes that are associated with the safety net. 

Pending Amount The total amount of all pending deals 
associated with the safety net. 

Available Amount The Safety Net Amount minus the 
Dealt Amount and Pending Amount. 
A similar process may be performed at each involved 
Market Access Node (MAN) using the Order Limit Avail- 
able and amount to verify that no active Order Limit Amount 
would otherwise be exceeded. 
Addition of Order to Order Limit 

A trader is allowed to submit a new order under an 
existing Order Limit only if the available amount in the 
Order Limit is more than the minimum notional amount. The 
workstation pre-populates the amount field in the order entry 
panel with the available Order Limit Amount if a trader 
decides to subject his order to the Order Limit. The amount 
field is dynamically updated whenever a message is received 
which reduces the available amount of the Order Limit. The 
trader is not allowed to change the amount of his order while 
subject to the Order Limit. 

The workstation validates the Order Limit Notional 
Amount (OLNA) with the Maximum Trade Size parameter 
set for that tenor. Similarly, if a trader decides to submit 
multiple orders under the Order Limit, then each of the 
orders is individually validated, as described above. All the 
orders failing the aforementioned validation is displayed in 
red and an error message "Trade SizoMax Trade Size" (not 
shown) is displayed at the bottom of the Order Panel (OP) 
just above the spin buttons (SB). 

Once a trader presses the Send Key, the workstation will 
fill the safety net ID field in the message with the safety net 
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ID that had been previously assigned to that Order Limit and 
will send the message to the banknode. Both the Tenor Line 
(PL) and the Tenor Detail Panel (TDP) of the submitting 
trader will show the Order Limit Indicator (OLI). 

The added order will not 'jump the queue* and in terms of 5 
the price/time continuum is placed in the queue on its own 
merit. There is no impact on the other orders or tenors under 
the Order Limit. However, orders already in the market 
cannot be made subject to a Order Limit without first 
canceling the original order, for example, by hitting one of 10 
the order keys (Buy/Bid/Sell/Offer) to thereby cancel the 
original order. 

Removal of Order from Order Limit 

A trader is allowed to remove a current order from an 
existing Order Limit. The workstation will cancel the order 15 
and will send an Interrupt message to the banknode. There 
is no impact on the other orders under the Order Limit. 

If some amount had already been taken from the order 
prior to it being removed, the Order Limit Amount has 
already been adjusted and would not change further as a 20 
result of the removal. The Order Limit Amount on the 
remaining orders subject to the same Order Limit would 
remain what it was immediately before that order was 
removed including any prior reduction in the original Order 
Limit Amount. 25 

Although the described embodiment does not include a 
Cancel Order Limit button which would automatically can- 
cel all orders under tbe Order Limit, a trader could highlight 
each tenor subject to the Order Limit and hit one of the order 
keys (Buy/Bid/Sell/Offer) and at this point, any outstanding 30 
Orders for the selected tenors would be canceled, whether or 
not they were subject to any Order Limit, A trader is not 
allowed to increase or decrease the amount of the Order 
Limit while orders are in the market subject to that Order 
Limit, 35 
Display of Order Amounts 

There is no requirement for any special handling of 
amounts of orders subject to the Order Limit different from 
other orders, although in an alternate embodiment (not 
shown), all involved traders (or at least those traders having 40 
bilateral credit with the trader submitting an order that is part 
of the displayed Available Amount (AA) may be given a 
visual indication that the displayed amounts are subject to a 
common Order Limit, and thus the amount actually avail- 
able in the market may be only a fraction of what is shown 45 
on his display. The amount displayed within each Tenor Line 
with an order subject to the Order Limit will typically 
correspond to the amount remaining in the Order Limit and 
available to the market (with the caveat that two tenors may 
be subject to a common Order Limit and thus the full 50 
available amount of the other tenor may not be available 
after the first is taken). The amount display in the Tenor 
Detail Panel for an order subject to the Order Limit typically 
will display in addition the original amount made available 
and possibly also the aforementioned indication of whether 55 
some or all of that amount is subject to a common Order 
Limit with one or more other tenors. 
Termination of Order Limit 

In order to prevent using an order limit to take unfair 
advantage of other traders by securing a favored position in 60 
the time/price queue maintained by the matching engine 
without a concomitant commitment to honor the order as 
originally submitted, it is desirable that the trader can neither 
cancel nor increase a particular Order Limit while there are 
any outstanding orders remaining in the market that were 65 
originally entered under that Order Limit. However, once all 
of the submitted orders have been dealt and/or canceled, so 
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that the trader's order no longer has a preferential position 
in any applicable queue, the trader may cancel that Order 
Limit prior to submitting any new orders, and the worksta- 
tion will send a message to the banknode to delete the Order 
Limit and will remove the Order Limit object. 

The banknode (MAN) or arbitrator (ARB) may cancel the 
Order Limit if any of the validations fail at their end. In that 
case, the banknode will automatically cancel all the orders 
under the Order Limit when it cancels the Order Limit, 
whereupon it will send a cancel message to the workstation. 
The workstation, upon receiving such a cancel message will 
check for any outstanding orders. If there are any outstand- 
ing orders subject to tbe Order Limit, then it will log an error. 
It will then cancel all the outstanding orders subject to the 
Order Limit and will remove the order limit object. 

Once the Order Limit Amount is exhausted or is below the 
minimum notional amount global parameter, the banknode 
will send a Done message to the workstation. The worksta- 
tion will check if the order limit object still exists. If it does 
not exist, then the workstation will ignore the message. 
Otherwise, it will check for any outstanding orders under 
this Order Limit. If there are any orders, it will log an error 
and will cancel all the remaining orders and will then 
remove the order limit object. 
Trading Floor Administration (TFA) Functions 

Preferably, at least one designated trader on each trading 
floor has the ability to set the following parameters: 

a) Notional Amount Increment 

The notional amount increment is a system-wide param- 
eter (per currency) specifying the increment between 
notional amount values specified during order submission. 
All orders submitted into the system must have a notional 
amount that is a multiple of this value. This parameter (and 
the corresponding Order Size parameter of all orders entered 
into the system) is preferably specified in absolute terms. 

b) Price Increment 

The price increment specifies the granularity between 
prices for orders submitted into the system. The increment is 
defined for each tenor or tenor category defined in the 
database of valid FRA instruments, and is preferably speci- 
fied in absolute terms. 

c) Minimum Notional Amount 

The minimum notional amount is a system-wide param- 
eter specified for each currency that specifies the minimum 
notional amount of an order submitted or outstanding in the 
system. If the remaining amount of an order falls below this 
value, then the remaining amount is canceled. This value is 
preferably expressed in three-month-equivalent terms since 
FRAs with shorter gaps are conventionally traded with 
higher notional amounts than similar FRAs with longer 
gaps.. 

d) Maximum Notional Amount 

The maximum notional amount is a system-wide param- 
eter (per currency) that specifies the maximum notional 
amount of an order submitted into the system. This value is 
also preferably expressed in three-month-equivalent terms. 

Alternatively, some or all of these parameters may be 
administered at a system level by a designated system 
administrator. In either case, the matching process in the 
Arbitrator, the order submission process in the individual 
workstations, and/or both have access to these parameters 
(and also to other system specified parameters not consid- 
ered relevant to the present invention) when executing 
matches. 

Overview of Deal Matching Process 

A match is not allowed to proceed if the credit utilization 
as calculated exceeds the available credit set by the TEA. 
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Thus, even though prescreened for credit, a further check of 
bids, offers, buy and sell order credit compatibility is done 
as part of deal matching. 

Orders that are compatible are matched by the dealing 
system. Newly submitted bid and buy orders are matched $ 
against outstanding offer orders. Newly submitted sell and 
offer orders are matched against outstanding bid orders. 

A new bid or buy order is compatible to an existing offer 
or sell order if all of the following conditions are true: 

The orders are for the same tenor. 

The trade floors of the orders are credit compatible with 
respect to this order - or • the trade floors of the two 
orders are identical. 

The price of the bid or buy order is greater than or equal 
to the offer or sell order. 

The amounts of both orders are greater than or equal to the 
3-month-equivalent of the system defined minimum 
notional amount parameter. 

Any order submitted into the system is first matched 
against all existing bids and offers at the maker's Arbitrator. 
The existing orders are considered in price/time order in 
search of compatible orders. If a compatible order is found, 
the two orders are "matched" and a deal is initiated for the 
amount equal to the minimum of the two order amounts. The 
process continues until the remaining three-month- 
equivalent amount of the submitted order becomes less than 25 
the value of the minimum notional amount parameter, or 
until there are no compatible orders. 

If the remaining three-month-equivalent amount of the 
submitted order is less than the value of the minimum 
notional amount parameter, the submitting workstation is 30 
informed accordingly and the order is canceled. 

When a newly submitted order is not completely filled 
during the auto match process, the order becomes either a bid 
or offer in the dealing system's collection of outstanding 
orders. The amount of the outstanding order is equal to the 35 
amount that was not matched during the automatch process. 

In order to complete a deal initiated during the automatch 
process, the dealing system must then verify in known 
fashion that both of the matched orders have not been 
removed by the trader and that there remains sufficient credit 40 
available to complete at least a system defined minimum 
deal size. 

The final deal amount is lesser of the initial deal amount, 
the available credit from the first floor (or other associated 
first credit granting entity) to the second floor (or other 45 
associated first Credit Group), the available credit from the 
second floor (or other associated second credit granting 
entity) to the second floor (or other associated second Credit 
Group), and the available amount in any applicable Order 
Limit. If any of these amounts is less than the 3 -month- 50 
equivalent of the minimum notional amount parameter, then 
the matching process for this deal fails. 

When matching quotes that are associated with the safety 
net, the arbitrator will allow a deal size up to the quote 
amount, or the Available Amount from the safety net, 55 
whichever is less. The matched amount will be added to the 
Safety Net Pending Amount. When the deal is done, the 
matched amount will be subtracted from the Pending 
Amount and the deal amount (which may be less than the 
matched amount) will be added to the Dealt Amount field. 60 
The Available Amount will then be recalculated. 
Deal Completion Process 

After a deal is initiated it is considered pending until the 
floors notify the responsible Arbitrator of the deal's status or 
the deal times out. 65 

The deal status reflects whether the deal was actually 
performed and what the amount of the deal was. The amount 



could be different from the initial amount of the deal due to 
credit or Order Limit restrictions. The Market processor 
records the deal information. If the deal was executed for an 
amount smaller than the original amount, the remaining 
amount may be available for another match. 

If the deal is subject to an Order Limit, the Dealt amount 
is increased by the final amount of the deal done. The 
Pending amount is reduced by the original amount of the 
deal. 

If a deal fails to complete, the amount tentatively matched 
will be subtracted from the Pending Amount and the Avail- 
able Amount (the original Safety net less any Dealt or 
Pending amounts) will be recalculated. The Safety Net 
completes when the Dealt Amount becomes equal to the 
Safety Net Amount. (Not when the Available Amount goes 
to zero, because the entire matched amount may not be dealt, 
thereby increasing the Available Amount to more than the 
Minimum Notional amount) At the same time, any outstand- 
ing quotes associated with the safety net are completed. No 
new quotes can be submitted under the same safety net. Any 
outstanding deals are allowed to finish normally. 
Exemplary Trading System Architecture 

In the described embodiment and as shown in FIG. 5, the 
trading system is an electronic brokerage system having a 
communication network for facilitating the buying and 
selling of futures by traders each associated with his own 
Workstation (" WS") located at a trading floor of a subscriber 
bank ("client site") and connected to a central Arbitrator 
(ARB), with at least the price and other market related data 
that is destined for more than one Market Access Node 
flowing through a shared Market Distributor (MD) node. For 
the most part, the hardware and most of the software used in 
this exemplary system is based on the current EBS system 
for foreign exchange and described in some detail in the 
referenced US patent, to which reference may be made. 
However, in part because a FRA involves only one currency, 
there are fewer interregional trades between geographically 
separated trading regions, and the overall design may be 
simplified by providing only one Arbitrator node. However, 
it may nevertheless be desirable to utilize the distributed 
credit utilization and dealable price screening functionality 
pioneered by the known EBS system. In particular, a single 
central Arbitrator could be dedicated to FRA trades, while 
several regionalArbitrators are collectively dedicated to spot 
FX trades, sharing the existing EBS communication network 
and trader workstations. 

Although the existing EBS architecture (hardware and 
software) can be as the base for the above described FRA 
trading system; any required changes will be largely isolated 
to the Graphical User Interface (GUI) on the Workstation 
and in the imposition of Order Limits (both of which being 
described in detail above) and the credit processing on the 
Banknode (which is the disclosed in a copending PCT 
application entitled "Communication of Credit Filtered 
Prices in an Electronic Brokerage System", which is hereby 
incorporated by reference). The rest of the EBS system 
architecture (price making, price taking, price distribution, 
deal matching, system administration, etc.) may be utilized 
by the individual FRA tenors in a manner analogous to 
individual currency pairs in the known EBS spot foreign 
exchange dealing system. 

It should be noted that a single central computer system 
could be used to implement the various functions described 
above. The system of this alternative embodiment would 
thus comprise a plurality of workstations connected by a 
network to a central computer system. This is a simpler, but 
non-preferred, implementation. The distributed embodiment 
described is considered to be a more robust and secure 
design. 
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What is claimed is: 

1. In a computerized trading system for permitting a trader 
to submit orders for display and acceptance by other traders, 
an improved multiple order facility comprising: 

sheet means for simultaneously displaying current market 5 
prices for a plurality of related financial instruments; 

multiple selection means for selecting at least two of said 
plurality of related instruments; 

price means for manually adjusting an associated price 
parameter for each of the selected instruments; 30 

order limit means for simultaneously setting an associated 
size parameter for all the selected instruments to a 
common order limit; and 

submission means for submitting respective orders each 
including a respective price parameter and a respective 15 
size parameter for each of the selected instruments to 
the other traders; 

wherein after any of the submitted orders subject to the 
common order limit is dealt on by any of the other 
traders for a particular deal size, the order limit means 20 
automatically reduces the size parameter of each of the 
other submitted orders subject to that same common 
order limit by an amount corresponding to that deal 
size. 

2. The multiple order facility of claim 1, wherein 

the common order limit is established by the trader 25 
submitting the selected instruments, the selected instru- 
ments in at least one said multiple order are not subject 
to such a common order limit, and 

the facility further comprises size means for manually 
adjusting the individual size parameters for at least 30 
those selected instruments not subject to any such 
common order limit. 

3. The multiple order facility of claim 1, wherein 

the orders submitted by the submitting means include bids ^ 
and offers from market makers and buy and sell orders 
from market takers 

the multiple selection means presents a market maker 
with a current market default price for those selected 
instruments for which a market price currently exists 40 
and a blank price for those selected instruments for 
which a market price does not currently exist; and 

the price means is adapted to be manipulated by the 
market maker to individually adjust the price of each of 
the selected instruments. 45 

4. The multiple order facility of claim 3, wherein 

the multiple selection means presents a market taker with 
a current market default price only for those selected 
instruments for which a market price currently exists; 
and 50 

the price means is adapted to be manipulated by the 
market maker to individually adjust the price of each of 
the instruments presented to the market taker by the 
multiple selection means. 

5. The multiple order facility of either of claims 3 or 4, 55 
further comprising group price means for simultaneously 
adjusting by a predetermined increment the prices of all of 
the instruments presented by the multiple selection means. 

6. The multiple order facility of claim 5 further compris- 
ing 60 

group size means for simultaneously adjusting by a pre- 
determined increment the sizes of all of the instruments 
presented by the multiple selection means. 

7. In a computerized trading system for permitting a first 
trader to submit a plurality of orders for display and accep- 65 
tance by other traders, an improved multiple order facility 
comprising: 
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(a) means for permitting the first trader to simultaneously 
generate a plurality of orders by: 

(1) selecting a plurality of financial instruments from a 
displayed list of related financial instruments, each 
selected financial instrument being associated with a 
respective one of the orders; 

(2) selecting a common quantity to be applied to each 
of the orders; 

(3) selecting, for each respective order, a respective 
price at which the first trader is willing to buy or sell 
the financial instrument associated with that order; 
and 

(4) sending each of the orders to a plurality of other 
traders using the computerized trading system; and 

(b) means displaying the orders at the terminals of the 
other traders to whom the orders were sent, each 
displayed order showing: 

(1) the price for the financial instrument associated with 
the order as selected by the first trader; and 

(2) an available quantity of the financial instrument 
associated with the order, the available quantity 
initially being equal to the common quantity set by 
the first trader and being reduced whenever a deal is 
made on any of the plurality of orders. 

8. The improved multiple order facility of claim 7, 
wherein the available quantity is reduced by an amount 
equal to the monetary value of any deal made on any of the 
plurality of orders. 

9. The improved multiple order facility of claim 8, 
wherein a deal is made when all or part of one of the orders 
made by the first trader is accepted by one of the other 
traders. 

10. The improved multiple order facility of claim 7, 
wherein the orders are bids and offers from market makers. 

11. The improved multiple order facility of claim 10, 
wherein the first trader is presented with information con- 
cerning available market prices for the financial instruments 
selected. 

12. Hie improved multiple order facility of claim 11, 
wherein the information concerning market prices is pro- 
vided at least at the time that the first trader selects, for each 
respective order, the price at which the first trader is willing 
to buy or sell the financial instrument associated with that 
order. 

13. The improved multiple order facility of claim 7, 
wherein the orders are buy and sell orders from market 
makers. 

14. The improved multiple order facility of claim 13, 
wherein the first trader is presented with information con- 
cerning available market prices for the financial instruments 
selected. 

15. The improved multiple order facility of claim 14, 
wherein the available market price information is presented 
at least at the time that the first trader selects, for each 
respective order, the price at which the first trader is willing 
to buy or sell the financial instrument associated with that 
order. 

16. The improved multiple order facility of claim 14, 
wherein the available market price information is presented 
at least at the time that the first trader selects, for each 
respective order, the price at which the first trader is willing 
to buy or sell the financial instrument associated with that 
order. 

17. The improved multiple order facility of claim 7, 
wherein the means for permitting allows the first trader to 
select the price for each respective order by manually 
varying a default price, the default price being set equal to 
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an available market price for the financial instrument asso- 20. The process of claim 19, wherein a deal is made when 

ciated with that order. all or part of one of the orders made by the first trader is 

18. A process for submitting a plurality of orders for accepted by one of the other traders. 

display and acceptance by other traders, comprising: 2 1. The improved multiple order facility of claim 18, 

(a) a first trader simultaneously generating a plurality of 5 wherein the orders are bids and offers from market makers, 
orders by: 22. The improved multiple order facility of claim 21, 

(1) selecting a plurality of : financial instruments from a whcrcin ^ first tfader ^ entcd with i n f ormati on con- 

displayed list of related financial instruments, each . .. , , , , c iL £ . . . A 

i i j c • i * * . i_ ■ • * j *it_ cerning available market prices lor the financial instruments 

selected financial instrument being associated with a ° r 

respective one of the orders; ™ selected. 

(2) selecting a common quantity to be applied to each 23 • improved multiple order facility of claim 22, 
of the orders; wherein the information concerning market prices is pro- 

(3) selecting, for each respective order, a respective vided at least at the time that the first trader selects, for each 
price at which the first trader is willing to buy or sell respective order, the price at which the first trader is willing 
the financial instrument associated with that order; 15 to buy or sell the financial instrument associated with that 
and order. 

(4) sending each of the orders to a plurality of other 2A The improved multiple order facility of claim 18, 
traders using the computerized trading system; and wherein ^ 0fders are buy and ^ Q ^ from mafket 

(b) displaying the orders at the terminals of the other makers 

0^^°" 1,16 ° r<lerS W6re SCnt ' CaCh djSPlayed ^ 2S - ^ topf0Ved multiple ° rder faciUty ° f Claim 24, 

W*u - , - . . , « si wherein the first trader is presented with information con- 

tne price for the financial instrument associatea with . , , , r t ^ . t • 

the order as selected by the first trader; and cermn S ™ a ^\c market prices for the financial instruments 

(2) an available quantity of the financial instrument selected. 

associated with the order, the available quantity 25 26 * ^ improved multiple order facility of claim 18, 

initially being equal to the common quantity set by wherein the first trader selects the price for each respective 

the first trader and being reduced whenever a deal is order by manually varying a default price, the default price 

made on any of the plurality of orders. being set equal to an available market price for the financial 

19. The process of claim 11, wherein the available quan- instrument associated with that order, 
tity is reduced by an amount equal to the monetary value of 30 

any deal made on any of the plurality of orders. ***** 
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SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR AUTHORIZING THE 

USE OF ELECTRONIC CONTENT 
UTILIZING A LASER-CENTRIC MEDIUM 

FIELD OF THE INVENTION 

The present invention relates to a distribution and tracking 
system that utilizes a set of bits on an electronic medium to 
track and control use of content electronically. 

BACKGROUND OF THE INVENTION 

The now familiar compact disk preserves information as 
a series of microscopic pits and smooth areas, oriented in 
concentric circular or helical tracks, on the otherwise 
smooth, planar surface of an annular disk. Recorded infor- 
mation is read from a compact disk by directing a focused 
laser beam along the recorded tracks, and detecting varia- 
tions in the intensity of the laser beam as it encounters the 
microscopic pits and smooth areas on the disk. The coher- 
ence and relatively short wavelength of laser radiation 
enables large volumes of information to be written onto very 
small spaces of a recording medium. 

Compact disks were first introduced in the music record- 
ing industry in 1982, and now account for 43% of all 
recorded music sales. In the United States alone, over three 
hundred million compact disks are sold annually, with a 
retail value of over three billion dollars, according to the 
Recording Industry Association of America. The recording 
industry has for the last ten years packaged the five inch in 
diameter prerecorded compact disks in six inch by twelve 
inch cardboard boxes known in the industry as "long boxes/' 
The long box is easily propped up in display bins alongside 
traditional vinyl LPs in music store display bins. More 
importantly, however, the bulk of the long box makes it 
difficult for a shoplifter to hide a prerecorded compact disk 
under a coat or in a purse and walk out of a music store 
without paying. While the long box packaging technique for 
prerecorded compact disks has been somewhat effective as 
an anti-theft device, the excess packaging it creates accounts 
for as much as twenty five million pounds of packaging 
waste annually. 

The Recording Industry Association of America accord- 
ingly announced in 1991 its intention to abandon the long 
box. In February of 1992, the Association announced that, 
beginning in April 1993, all prerecorded compact disks 
would be marketed in five inch by five and one half inch 
packages. 

When Compact Discs (CD)s or Digital Video or Versatile 
Disks (DVD)s are manufactured, they are frequently trans- 
ported and stored on spindles. This is at least in part due to 
the fragile nature of the storage medium. Since each disk has 
a center hole, is relatively thin and is relatively light, storage 
of multiple discs on a spindle is convenient. Spindles, as 
used in the manufacture of disks, typically have a central 
post about two feet long and weighted base about two inches 
thick. Depending upon the level of automation of the disk 
manufacturing process, disks may be stored or carried on 
spindles several times before printing or packaging. In the 
most fully automated processes, disks are only kept on 
spindles between the inspection and printing steps and just 
prior to final packaging. In more manual systems, disks may 
be placed on spindles between every manufacturing step 
including between molding and metalizing, between metal- 
izing and spin coating, between spin coating and inspection, 
between inspection and printing, and between printing and 
final packaging. However, regardless of the number of times 
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the disks are maintained on spindles, each such time the disk 
is removed for processing, a possibility of theft and confu- 
sion as to title exists. In other words, whenever a disk is on 
a spindle, particularly without any identifying printing, the 
5 identification of the title on that spindle may easily be called 
into question or be confused. It is essential that a capability 
be built into a disk to track the disk and provide distribution 
management, quality control and customer access informa- 
tion. 

10 Similarly, whenever disks are maintained on a spindle for 
any length of time, theft can occur. Without any means of 
preventing unauthorized removal of disks from the spindle 
or tracking exactly how many disks were on the spindle, 
thefts regularly happen. 

15 The merchandising of compact disc (hereinafter "CD") 
multimedia is a growing industry. CD multimedia are used 
in audio, video, audio -video, and computer based applica- 
tions. Since many similar looking duplicate recordings for a 
particular CD program are often available from many dif- 

20 ferent sources, it is difficult for merchants to track, identify, 
and distinguish their inventory from the inventory of others. 

Security is an important concern associated with the 
rental, loan, or sale of such merchandise. Items such as 
commercially prerecorded compact disc programs are avail- 

25 able from rental shops, stores, and libraries. It is important 
for a merchant to have a simple means to secure and identify 
its merchandise. For example, a merchant needs to deter- 
mine whether merchandise which was rented from it is the 
same merchandise that is being returned to it to deter 

30 customers from attempting to switch good rented merchan- 
dise with bad return merchandise (such as a customer's 
scratched disc). 

The switching of CDs in good condition with defective 
CDs obtained from other sources is a difficult problem that 

35 merchants face. Merchandise switching is a significant prob- 
lem given the high volume of business involved in the 
compact disc industry and the difficulty of detecting such 
illegal switching. An easy and reliable way for a merchant 
to determine whether the digital data contained on a CD is 

40 damaged or defective is required. Although obvious imper- 
fections such as scratches or cracks may be detected by a 
simple visual inspection, such inspection cannot detect 
defects in the digital data. Even though defects may be 
discovered during regular speed playback of an entire CD, 

45 such means is commercially impractical since it requires too 
much time for merchants dealing in high volume to check 
every CD returned to them. Although high-speed electronic 
scanning devices for checking digital recordings currently 
exist, such devices are effectively unavailable to the indi- 

50 vidual merchant due to cost prohibitions and the limited 
availability of such technology. 

Electronic article surveillance systems for monitoring the 
egress of sensitive objects from controlled spaces are well 
known, and have been used alone and along with the long 

55 box packaging technique for controlling the unauthorized 
taking of compact disks. Markers formed from a piece of 
high permeability magnetic material can be placed on the 
packaging for the disk. Spaced apart detection panels are 
then placed across the access points to the store, library or 

60 other repository for the monitored compact disks. The panels 
include field coils and detector coils for producing a mag- 
netic field across the access point that can detect the passage 
of a marker between the panels. If a person attempts to carry 
a compact disk through the magnetic field presented by the 

65 panels without first deactivating the marker on the disk 
packaging, the presence of the marker will be detected and 
an alarm initiated. 
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U.S. Pat. No. 4,710,754 discloses a multi-directional EAS 
marker especially designed for its compact dimensions. The 
marker disclosed in the '754 patent is comprised of a high 
permeability, low coercive force, generally planar magnetic 
responder material that includes at least two narrow regions 5 
defining switching sections, and adjacent, wider, flux col- 
lector sections. The juxtaposition of the narrow switching 
sections with the flux collector sections causes the flux to be 
highly concentrated in the switching sections. The high 
concentration of flux lines in the switching sections pro- 10 
duces high frequency harmonics when passed through an 
alternating magnetic field, allowing the presence of the 
marker in the field to be detected. The marker is conve- 
niently made dual status, i.e., reversibly deactivatable and 
reactivatable, by including a piece of magnetizable material ^ 
adjacent each of the switching sections. The magnetizable 
material, when magnetized, biases the adjacent switching 
section to either keep the magnetization therein from revers- 
ing when in an alternating interrogation field, or at least 
altering the response of the marker in the field. In either case, 20 
readily distinguish ably different signals are produced by the 
marker in an interrogation field depending on whether the 
magnetizable material is magnetized or demagnetized. 

U.S. Pat. No. 4,967,185 discloses a multi-directional, 
dual-status EAS marker also designed for its compact 25 
dimensions. The marker disclosed in the '185 patent dis- 
closes a marker that includes a continuous uninterrupted 
sheet of remanently magnetizable material overlying a sheet 
of responder material similar to that disclosed in the '754 
patent. The response of the marker within an alternating 30 
magnetic field can be discernably altered by selectively 
magnetizing and demagnetizing the continuous sheet of 
remanently magnetizable material prior to introducing the 
marker into the field. The markers disclosed in the above 
noted prior art can be attached to the packaging for a 35 
compact disk. Problems arise, however, when attempting to 
attach prior art markers directly to the surface of a compact 
disk. Rotation of the compact disk is required to read 
information from the disk, and the disk must accordingly be 
inherently balanced. An EAS marker, applied directly to a 40 
compact disk, therefor, would preferably be somehow con- 
centrically mounted on the disk without unbalancing the 
disk. Prior art EAS markers, however, are not inherently 
balanced. Moreover, conventional compact disks include a 
centered aperture that must be maintained clear of 45 
obstructions, and the preferred prior art dual status EAS 
markers include a continuous sheet of magnetic material, 
such that the marker cannot be concentrically mounted to the 
surface of a compact disk without obstructing the disk 
aperture. 50 

U.S. Pat. No. 4,709,813 proposed an anti-theft device for 
compact disks that overcame the inability to directly apply 
an EAS marker to the surface of a compact disk. The '813 
patent discloses a detachable locking plate with an EAS 
marker carried on the internal face of the plate that can be 55 
selectively locked to the "jewelry box" for a compact disk. 
The compact disk is physically locked in the box leg by the 
plate. A clerk or other authorized person can remove the 
plate with the use of a keyed release tool at the time of 
payment. It will be appreciated that the use of a locking plate 60 
requires preparation time to attach a plate to each compact 
disk cartridge, adds an additional step in the check-out 
process, and leaves the compact disk without EAS protec- 
tion once the EAS marker carrying plate is removed from the 
compact disk. The lack of EAS protection once the plate is 65 
removed makes it especially risky for a retailer to permit the 
trial playing of a compact disk by a customer in the store 
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before the compact disk is purchased. The new packaging 
standard for prerecorded compact disks, while environmen- 
tally sound, will exacerbate the problem of compact disk 
shop lifting, since the smaller packages will be easier to hide 
and transport out of a store. 

While the use of electronic article surveillance systems 
could partially compensate for the increased shoplifting 
threat, it will be appreciated that the unauthorized removal 
of the magnetic markers from a package will defeat the 
detection capability of the surveillance system, and known 
EAS markers cannot be directly mounted on a compact disk 
without affecting the operability of the disk. The use of an 
EAS marker in conjunction with a locking plate presents 
handling problems and does not solve the problem of 
physical security of compact disks at stores where the 
customer is allowed to listen to the compact disk prior to 
purchase. A new, compact optical information disk espe- 
cially designed for tamper-proof use with an electronic 
article surveillance system through the use of an EAS 
marker that could be applied directly to the surface of the 
compact disk would accordingly provide decided advan- 
tages. Thus, there is a need for merchants to conveniently 
and inexpensively maintain the security of their electronic 
content medium. 

SUMMARY OF THE INVENTION 

A system, method, and article of manufacture is provided 
for tracking the distribution of content electronically. First, 
an electronic storage medium tracking identifier is incorpo- 
rated onto an electronic storage medium and stored on a 
database. Next, a package tracking identifier is situated onto 
a package in which the electronic storage medium is stored. 
Hie electronic storage medium is then tracked while being 
shipped between various entities using the tracking identifier 
on the package. Further, the electronic storage medium may 
be identified using the tracking identifier on the electronic 
storage medium in order to afford authorized use of the 
information contained on the electronic storage medium. 

DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages 
are better understood from the following detailed description 
of a preferred embodiment of the invention with reference to 
the drawings, in which: 

FIG. 1 is a general block diagram of the method of 
tracking an electronic medium in accordance with the 
present invention; 

FIG. 2 is a detailed block diagram of the method of 
tracking the electronic medium in accordance with a pre- 
ferred embodiment; 

FIG. 3 is a block diagram of an embodiment of the 
hardware involved with one embodiment of the present 
invention; 

FIG. 4 is a pictorial representation of a comparison of the 
prior lifecycle of electronic storage medium and the elec- 
tronic storage medium of the present invention; 

FIG. 5 is a block diagram of a user experience in 
accordance with a preferred embodiment; 

FIG. 6 is a flowchart of a redirect operation for an 
electronic commerce transaction in accordance with a pre- 
ferred embodiment; 

FIGS. 7A and 7B are flowcharts setting forth the detailed 
logic associated with user connection and update for DVD 
processing in accordance with a preferred embodiment; 

FIG. 8 presents logic demonstrating the display of specific 
advertising information based on a retailer/distributor uti- 
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lizing BCA information for intelligent processing in accor- 
dance with a preferred embodiment; 

FIG. 9 is a flowchart demonstrating the display of specific 
advertising information based on genre/type of DVD utiliz- 
ing BCA information for intelligent processing in accor- 5 
dance with a preferred embodiment; 

FIG. 10 is a flowchart of a download operation for 
downloading and updating retailer-specific information of 
the DVD utilizing BCA information for intelligent process- 
ing in accordance with a preferred embodiment; 10 

FIG. 11 is a flowchart of a download operation for 
downloading and updating DVD title-specific information 
utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment; 

FIG. 12 is a flowchart of a tailored video viewing opera- 
tion utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment; 

FIG. 13 is a flowchart of a tailored video viewing opera- 
tion utilizing BCA information for intelligent processing in 20 
accordance with a preferred embodiment; 

FIG. 14 is a flowchart of the logic associated with a 
tailored multimedia viewing operation utilizing BCA infor- 
mation for intelligent processing in accordance with a pre- 
ferred embodiment; 25 

FIG. 15 is a flowchart of a security operation for restrict- 
ing access to specific web sites utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment: 

30 

FIG. 16 is a flowchart of a unlock operation for an 
electronic commerce transaction utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment; 

FIG. 17 is a flowchart of an unlocking operation for an 35 
electronic commerce transaction utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment; 

FIG. 18 is a flowchart of a logging operation for tracking 
piracy and misuse of a DVD utilizing BCA information for 40 
intelligent processing in accordance with a preferred 
embodiment; 

FIG. 19 is a flowchart of a redirect operation for a support 
transaction for intelligent processing in accordance with a 
preferred embodiment; 45 

FIG. 20 is a flowchart of a display operation for a support 
transaction for intelligent processing in accordance with a 
preferred embodiment; 

FIG. 21 is a flowchart of support tracking utilizing BCA 5Q 
for intelligent processing in accordance with a preferred 
embodiment; 

FIG. 22 is a flowchart of a redirect operation for a support 
transaction for intelligent processing in accordance with a 
preferred embodiment; and 55 

FIG. 23 is a flowchart of a broadcast operation for 
downloading update, support and application information 
utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment. 

DETAILED DESCRIPTION 60 

The present invention includes a system, method and 
article of manufacture for tracking the distribution of content 
electronically and providing intelligent services based on 
this information. FIG. 1 is a general block diagram of the 65 
method of tracking an electronic medium in accordance with 
the present invention. Initially, content in the form of music, 
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video, data, or any other type of visual or audible entertain- 
ment or information is generated in operations 10 and 12. 
Thereafter, an electronic storage medium tracking identifier, 
such as the Burst Cut Area (BCA) is incorporated onto an 
electronic storage medium 22 at the time of manufacture. It 
should be noted that the electronic storage medium 22 may 
take the form of any electronic/optic storage medium 
capable of storing content. In the present description, 
however, focus will remain on one embodiment of electronic 
storage medium, a DVD. 

As shown in FIG. 1, after the generation of the content, 
the electronic storage medium may be replicated by a 
replicator in operation 14. Further, a package tracking iden- 
tifier is incorporated onto a package in which the electronic 
storage medium is stored. Such tracking identifiers are then 
stored in a database. 

In use, the electronic storage medium may be tracked 
from a distributor to a retailer and the consumer in steps 16, 
18, and 20. This tracking is enabled by using the tracking 
identifier on the package 22 while the electronic storage 
medium is shipped between various entities such as the 
replicator, distributor, retailer, and consumer. Furthermore, 
when a final user obtains the electronic storage medium, the 
electronic storage medium may be identified using the 
tracking identifier on the electronic storage medium 22. As 
will become apparent hereinafter, various features may be 
afforded by identifying the electronic storage medium. 

As mentioned earlier, the electronic storage medium may 
be tracked by using the tracking identifier on the package 
while the electronic storage medium is shipped between 
various entities such as a replicator, distributor, retailer, and 
consumer. Specifically, the replicator is the company that 
manufactures, or "presses", the DVD. The replicator 
receives a DLT (digital linear tape) from the content devel- 
oper (studio such as New Line) and then creates a "glass 
master" of the DVD based on the data on the DLT. The glass 
master then becomes the master DVD from which all 
replicated DVDs are made. The replicator adds the BCA 
number to each DVD as part of the replication process and 
then "packages/boxes" the DVDs for distribution to a dis- 
tributor or retailer. 

The distributor, on the other hand, is the company that 
packages together multiple titles together for distribution to 
a retailer. The value of a distributor is that they maintain 
direct relationships and channels with the retailers, can 
maintain larger inventories of products — leveraging econo- 
mies of scale not possible by smaller retailers. A retailer 
requests multiple products from the distributor (for example 
20 copies of Lost in Space, 50 copies of Ronin, and 100 
copies of You've Got Mail — all of which come from dif- 
ferent studios), then the distributor can "package" the variety 
of products together for distribution to the retailer. 

Finally, the retailer is the company that sells product 
directly to consumer. Examples include "brick-and-mortar" 
stores such as Blockbuster Video, Hollywood Video, Best 
Buy, Good Guys, etc. Retailers also include online retailers 
such as DVDExpress, Amazon.com, and other e-commerce- 
oriented companies. Other groups are also joining the retail- 
ing opportunity, such as Nimbus who already offers both 
replication and distribution. It is the next logical step to offer 
direct-to -consumer online sales of product. It should be 
noted that the aforementioned replicator may also be the 
distributor (Nimbus/Technicolor, WAMO/Deluxe). Also, 
replicators may ship directly to retailers, especially in the 
case of large accounts like Blockbuster. 

Example in Accordance with a Preferred 
Embodiment 

An example setting forth details relating to the tracking of 
DVDs will now be set forth. First, a content owner (such as 
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studio) requests use of the BCA on their DVDs. Based on 
request, the replicator (examples include WAMO, 
Panasonic, Nimbus, Technicolor, Pioneer, Crest) adds 
unique BCA number to every DVD. Adding BCA number to 
each DVD requires a special (YAG) laser. This may be the 5 
very last step in the manufacturing process. The BCA 
numbers for a specific DVD must then be entered into 
Inter Actual's BCA database. Information to track includes: 
DVD title, i.e. "Lost in Space"; BCA #/range, i.e. 
12345687890; and Shipping Packaging/Tracking Container, 10 
i.e. Box 52221 to Hollywood Video. 

After the BCA number is added to the DVDs, the DVDs 
are packaging/boxed for distribution to either the Distributor 
or the Retailer. It should be noted that many companies take 
multiple forms, so the replicator and distributor may be one 15 
in the same. Also, some retailers are large/important enough 
to get shipments directly from replicator. The way in which 
the DVDs are packaging/shipped is very important because 
one must track the BCA numbers to actual shipping con- 
tainers (box, etc.). Therefore tracking information must also 20 
be added to the BCA database. 

If packaged DVDs are then sent to distributor, the dis- 
tributor also has mechanisms, i.e. scanners, input device, 
and monitoring devices, in place for tracking based on their 
distribution. For example, Deluxe may receive a "package" 25 
of 100,000 copies of "Lost in Space". However, the dis- 
tributor ships 10,000 to Retailer A and 5,000 to Retailer B. 
The distributor should be able to "input" retailer A and B's 
distribution information into the system. Ideally, this 
becomes a seamless/automated process. 30 

Once the DVDs reach the retailer (either from the repli- 
cator or distributor), then DVDs may be further divided and 
distributed to local stores/outlets. In such a situation, the 
retailer should be able to automatically "track" distribution 35 
of these DVDs through to their stores. Over time, all three 
entitities (replicator, distributor, and retailer) are able to add 
tracking information to BCA database. Due to complexity 
and dependencies on existing business systems, the retail 
tracking concept will be rolled out in phases: replicator first 4Q 
most likely with key retail accounts. The distributors will be 
brought in. Retailers will then begin to embrace the ability 
to track based on local outlet/store. 

Utilization of BCA Identification at the End 

Consumer 45 

As mentioned earlier, when a final user obtains the 
electronic storage medium, the electronic storage medium 
may be identified using the tracking identifier on the elec- 
tronic storage medium. By this identification, various fea- 50 
tures may be executed upon identification of the electronic 
storage medium. It should be noted that, in one embodiment, 
identification is carried out by a computer and software 
governs the features that are executed after identification of 
the electronic storage medium. 55 

For example, the present invention may be practiced in 
the context of a personal computer such as an IBM com- 
patible personal computer, Apple Macintosh computer or 
UNIX based workstation. A representative hardware envi- 
ronment is depicted in FIG. 3, which illustrates a typical 60 
hardware configuration of a workstation in accordance with 
a preferred embodiment having a central processing unit 
110, such as a microprocessor, and a number of other units 
interconnected via a system bus 112. The workstation shown 
in FIG. 3 includes a Random Access Memory (RAM) 114, 65 
Read Only Memory (ROM) 116, an I/O adapter 118 for 
connecting peripheral devices such as disk storage units 120 
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to the bus 112, a user interface adapter 122 for connecting 
a keyboard 124, a mouse 126, a speaker 128, a microphone 
132, and/or other user interface devices such as a touch 
screen (not shown) to the bus 112, communication adapter 
134 for connecting the workstation to a communication 
network (e.g., a data processing network) and a display 
adapter 136 for connecting the bus 112 to a display device 
138. The workstation typically has resident thereon an 
operating system such as the Microsoft Windows NT or 
Windows/95 Operating System (OS), the IBM OS/2 oper- 
ating system, the MAC OS, or UNIX operating system. 
Those skilled in the art will appreciate that the present 
invention may also be implemented on platforms and oper- 
ating systems other than those mentioned. 

A preferred embodiment is written using JAVA, C, and the 
C++ language and utilizes object oriented programming 
methodology. Object oriented programming (OOP) has 
become increasingly used to develop complex applications. 
As OOP moves toward the mainstream of software design 
and development, various software solutions require adap- 
tation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be applied to a messaging 
interface of an electronic messaging system such that a set 
of OOP classes and objects for the messaging interface can 
be provided, 

OOP is a process of developing computer software using 
objects, including the steps of analyzing the problem, 
designing the system, and constructing the program. An 
object is a software package that contains both data and a 
collection of related structures and procedures. Since it 
contains both data and a collection of structures and 
procedures, it can be visualized as a self-sufficient compo- 
nent that does not require other additional structures, pro- 
cedures or data to perform its specific task. OOP, therefore, 
views a computer program as a collection of largely autono- 
mous components, calied objects, each of which is respon- 
sible for a specific task. This concept of packaging data, 
structures, and procedures together in one component or 
module is called encapsulation. 

In general, OOP components are reusable software mod- 
ules which present an interface that conforms to an object 
model and which are accessed at run-time through a com- 
ponent integration architecture. A component integration 
architecture is a set of architecture mechanisms which allow 
software modules in different process spaces to utilize each 
others capabilities or functions. This is generally done by 
assuming a common component object model on which to 
build the architecture. It is worthwhile to differentiate 
between an object and a class of objects at this point. An 
object is a single instance of the class of objects, which is 
often just called a class. A class of objects can be viewed as 
a blueprint, from which many objects can be formed. 

OOP allows the programmer to create an object that is a 
part of another object. For example, the object representing 
a piston engine is said to have a composition-relationship 
with the object representing a piston. In reality, a piston 
engine comprises a piston, valves and many other compo- 
nents; the fact that a piston is an element of a piston engine 
can be logically and semantically represented in OOP by two 
objects. 

OOP also allows creation of an object that "depends 
from" another object. If there are two objects, one repre- 
senting a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the 
relationship between the two objects is not that of compo- 
sition. A ceramic piston engine does not make up a piston 
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engine. Rather it is merely one kind of piston engine that has 
one more limitation than the piston engine; its piston is made 
of ceramic. In this case, the object representing the ceramic 
piston engine is called a derived object, and it inherits all of 
the aspects of the object representing the piston engine and 5 
adds further limitation or detail to it. The object representing 
the ceramic piston engine "depends from" the object repre- 
senting the piston engine. The relationship between these 
objects is called inheritance. 

When the object or class representing the ceramic piston 10 
engine inherits all of the aspects of the objects representing 
the piston engine, it inherits the thermal characteristics of a 
standard piston defined in the piston engine class. However, 
the ceramic piston engine object overrides these ceramic 
specific thermal characteristics, which are typically different 
from those associated with a metal piston. It skips over the 
original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different 
characteristics, but may have the same underlying functions 
associated with it (e.g., how many pistons in the engine, 
ignition sequences, lubrication, etc.). To access each of these 
functions in any piston engine object, a programmer would 
call the same functions with the same names, but each type 
of piston engine may have different/overriding implemen- 
tations of functions behind the same name. This ability to 
hide different implementations of a function behind the same 
name is called polymorphism and it greatly simplifies com- 
munication among objects. 

With the concepts of composition-relationship, 
encapsulation, inheritance and polymorphism, an object can 3Q 
represent just about anything in the real world. In fact, our 
logical perception of the reality is the only limit on deter- 
mining the kinds of things that can become objects in 
object-oriented software. Some typical categories are as 
follows: 

Objects can represent physical objects, such as automo- 
biles in a traffic-flow simulation, electrical components 
in a circuit-design program, countries in an economics 
model, or aircraft in an air- traffic-control system. 

Objects can represent elements of the computer-user 40 
environment such as windows, menus or graphics 
objects. 

An object can represent an inventory, such as a personnel 
file or a table of the latitudes and longitudes of cities. 

An object can represent user-defined data types such as 45 
time, angles, and complex numbers, or points on the 
plane. 

With this enormous capability of an object to represent 
just about any logically separable matters, OOP allows the 
software developer to design and implement a computer 50 
program that is a model of some aspects of reality, whether 
that reality is a physical entity, a process, a system, or a 
composition of matter. Since the object can represent 
anything, the software developer can create an object which 
can be used as a component in a larger software project in 55 
the future. 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 
able objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. 60 
Since 90% already came from an inventory of extensively 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 
OOP enables software developers to build objects out of 
other, previously built objects. 65 

This process closely resembles complex machinery being 
built out of assemblies and sub-assemblies. OOP 
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technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the 
OOP principles, such as encapsulation, inheritance, 
polymorphism, and composition-relationship. With the 
advent of the C++ language, many commercial software 
developers have embraced OOP. C++ is an OOP language 
that offers a fast, machine-executable code. Furthermore, 
C++ is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be 
the most popular choice among many OOP programmers, 
but there is a host of other OOP languages, such as 
Smalltalk, Common Lisp Object System (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more 
traditional popular computer programming languages such 
as Pascal. 

The benefits of object classes can be summarized, as 
follows: 

Objects and their corresponding classes break down com- 
plex programming problems into many smaller, sim- 
pler problems. 

Encapsulation enforces data abstraction through the orga- 
nization of data into small, independent objects that can 
communicate with each other. Encapsulation protects 
the data in an object from accidental damage, but 
allows other objects to interact with that data by calling 
the object's member functions and structures. 

Subclassing and inheritance make it possible to extend 
and modify objects through deriving new kinds of 
objects from the standard classes available in the sys- 
tem. Thus, new capabilities are created without having 
to start from scratch. 

Polymorphism and multiple inheritance make it possible 
for different programmers to mix and match character- 
istics of many different classes and create specialized 
objects that can still work with related objects in 
predictable ways. 

Class hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real -world objects 
and the relationships among them. 

Libraries of reusable classes are useful in many situations, 
but they also have some limitations. For example: 

Complexity. In a complex system, the class hierarchies for 
related classes can become extremely confusing, with 
many dozens or even hundreds of classes. 

Flow of control. A program written with the aid of class 
libraries is still responsible for the flow of control (i.e., 
it must control the interactions among all the objects 
created from a particular library). The programmer has 
to decide which functions to call at what times for 
which kinds of objects. 

Duplication of effort. Although class libraries allow pro- 
grammers to use and reuse many small pieces of code, 
each programmer puts those pieces together in a dif- 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes 
along the way. Inevitably, similar pieces of code end up 
doing similar things in slightly different ways and do 
not work as well together as they should. 

Class libraries are very flexible. As programs grow more 
complex, more programmers are forced to reinvent basic 
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solutions to basic problems over and over again. A relatively 
new extension of the class library concept is to have a 
framework of class libraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 5 
mechanisms that implement the common requirements and 
design in a specific application domain. They were first 
developed to free application programmers from the chores 
involved in displaying menus, windows, dialog boxes, and 
other standard user interface elements for personal comptit 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer called libraries provided by 
the operating system to perform certain tasks, but basically 15 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 20 

The development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These interfaces allow the user, rather than program logic, to 
drive the program and decide when certain actions should be 
performed. Today, most personal computer software accom- 2 s 
plishes this by means of an event loop which monitors the 
mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, 
a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
a program that is much easier to use. Nevertheless, indi- 
vidual pieces of the program written by the developer still 
call libraries provided by the operating system to accomplish 35 
certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the 
event loop. Application code still "sits on top of the system. 

Even event loop programs require programmers to write 
a lot of code that should not need to be written separately for 40 
every application. The concept of an application framework 
carries the event loop concept further. Instead of dealing 
with all the nuts and bolts of constructing basic menus, 
windows, and dialog boxes and then making these things all 
work together, programmers using application frameworks 45 
start with working application code and basic user interface 
elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework 
with the specific capabilities of the intended application. 

Application frameworks reduce the total amount of code 50 
that a programmer has to write from scratch. However, 
because the framework is really a generic application that 
displays windows, supports copy and paste, and so on, the 
programmer can also relinquish control to a greater degree 
than event loop programs permit. The framework code takes 55 
care of almost all event handling and flow of control, and the 
programmer's code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data 
structure). 

A programmer writing a framework program not only 60 
relinquishes control to the user (as is also true for event loop 
programs), but also relinquishes the detailed flow of control 
within the program to the framework. This approach allows 
the creation of more complex systems that work together in 
interesting ways, as opposed to isolated programs, having 65 
custom code, being created over and over again for similar 
problems. 



Thus, as is explained above, a framework basically is a 
collection of cooperating classes that make up a reusable 
design solution for a given problem domain. It typically 
includes objects that provide default behavior (e.g., for 
menus and windows), and programmers use it by inheriting 
some of that default behavior and overriding other behavior 
so that the framework calls application code at the appro- 
priate times. 

There are three main differences between frameworks and 
class libraries: 

Behavior versus protocol. Class libraries are essentially 
collections of behaviors that you can call when you 
want those individual behaviors in your program. A 
framework, on the other hand, provides not only behav- 
ior but also the protocol or set of rules that govern the 
ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide 
versus what the framework provides. 

Call versus override. With a class library, the code the 
programmer instantiates objects and calls their member 
functions. It's possible to instantiate and call objects in 
the same way with a framework (i.e., to treat the 
framework as a class library), but to take full advantage 
of a framework's reusable design, a programmer typi- 
cally writes code that overrides and is called by the 
framework. The framework manages the flow of con- 
trol among its objects. Writing a program involves 
dividing responsibilities among the various pieces of 
software that are called by the framework rather than 
specifying how the different pieces should work 
together. 

Implementation versus design. With class libraries, pro- 
grammers reuse only implementations, whereas with 
frameworks, they reuse design. A framework embodies 
the way a family of related programs or pieces of 
software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in 
a given domain. For example, a single framework can 
embody the way a user interface works, even though 
two different user interfaces created with the same 
framework might solve quite different interface prob- 
lems. 

Thus, through the development of frameworks for solu- 
tions to various problems and programming tasks, signifi- 
cant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the 
invention utilizes HyperText Markup Language (HTML) to 
implement documents on the Internet together with a 
general-purpose secure communication protocol for a trans- 
port medium between the client and the Newco. HTTP or 
other protocols could be readily substituted for HTML 
without undue experimentation. Information on these prod- 
ucts is available in T. Berners-Lee, D. Connoly, "RFC 1866: 
Hypertext Markup Language — 2.0" (November 1995); and 
R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. 
Mogul, "Hypertext Transfer Protocol— HTTP/1.1: HTTP 

Working Group Internet Draft" (May 2, 1996). HTML is 
a simple data format used to create hypertext documents that 
are portable from one platform to another. HTML docu- 
ments are SGML documents with generic semantics that are 
appropriate for representing information from a wide range 
of domains. HTML has been in use by the Worldwide Web 
global information initiative since 1990. HTML is an appli- 
cation of ISO Standard 8879; 1986 Information Processing 
Text and Office Systems — Standard Generalized Markup 
Language (SGML). 

To date, Web development tools have been limited in their 
ability to create dynamic Web applications that span from 
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client to server and interoperate with existing computing 
resources. Until recently, HTML has been the dominant 
technology used in development of Web-based solutions. 
However, HTML has proven to be inadequate in the fol- 
lowing areas: s 
Poor performance; 

Restricted user interface capabilities; 

Can only produce static Web pages; 

Lack of interoperability with existing applications and 

data; and 10 
Inability to scale. 

Sun Microsystem's Java language solves many of the 
client-side problems by: 

Improving performance on the client side; 
Enabling the creation of dynamic, real-time Web appli- 15 
cations; and 

Providing the ability to create a wide variety of user 
interface components. 

With Java, developers can create robust User Interface 
(UI) components. Custom "widgets" (e.g., real-time stock ^ 
tickers, animated icons, etc.) can be created, and client -side 
performance is improved. Unlike HTML, Java supports the 
notion of client-side validation, offloading appropriate pro- 
cessing onto the client for improved performance. Dynamic, 
real-time Web pages can be created. Using the above- 
mentioned custom UI components, dynamic Web pages can 25 
also be created. 

Sun's Java language has emerged as an industry - 
recognized language for "programming the Internet." Sun 
defines Java as: "a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, portable, 30 
high-performance, multithreaded, dynamic, buzzword- 
compliant, general-purpose programming language. Java 
supports programming for the Internet in the form of 
platform -independent Java applets." Java applets are small, 
specialized applications that comply with Sun's Java Appli- 35 
cation Programming Interface (API) allowing developers to 
add "interactive content" to Web documents (e.g., simple 
animations, page adornments, basic games, etc.). Applets 
execute within a Java-compatible browser (e.g., Netscape 
Navigator) by copying code from the server to client. From 4Q 
a language standpoint, Java's core feature set is based on 
C++. Sun's Java literature states that Java is basically, "C++ 
with extensions from Objective C for more dynamic method 
resolution." 

Another technology that provides similar function to 
JAVA is provided by Microsoft and ActiveX Technologies, 45 
to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D vir- 
tual reality, video and other multimedia content. The tools 
use Internet standards, work on multiple platforms, and are 50 
being supported by over 100 companies. The group's build- 
ing blocks are called ActiveX Controls, small, fast compo- 
nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 55 
ing Microsoft Visual C++, Borland Delphi, Microsoft Visual 
Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of 6Q 
ordinary skill in the art readily recognizes that ActiveX 
could be substituted for JAVA without undue experimenta- 
tion to practice the invention. 

System Software in Accordance With a Preferred 

Embodiment $5 

When a consumer purchases DVD at local store, or 
purchases online through online retailer a new DVD is 



available for consumer use. The consumer places the DVD 
in a computer and the DVD initiates an online session 
between the user and an Internet server application in tight 
communication with the DVD in the DVD-ROM drive. 
Three BCA usage cases include: 

(1) a consumer launches a browser and goes to a web site 
that utilizes the BCA information to look up informa- 
tion in a database. The database is also updated with 
information gleaned from the current user and their 
demographics. 

(2) a local application (like PCFriendly) automatically 
connects to Internet and to a web server that looks up 
and/or acts on BCA information, or 

(3) a local application like PCFriendly utilizes informa- 
tion already contained in the BCA number and tailors 
experience locally based on this information. 

The details associated with the various cases will be 
discussed. Case 1: go to web site that looks up BCA With 
a DVD in their drive, consumer connects to a special web 
site that has an agent/component embedded on the web page 
that can read the BCA information. This embedded compo- 
nent reads the BCA, along with other potential information 
(user id, etc.), passes this information to the web server. The 
web server then tailors a response to the consumer based on 
pre-defined conditions/marketing/profile . 

Case 2: local application (like PCFriendly client software) 
automatically connects to a web server (without manual 
intervention of consumer) and passes BCA information to 
the web server. Based on the BCA number and other 
potential information, the web server passes information to 
the consumer's client software or presents remote Internet- 
based information based on this information/profile/retailer/ 
etc. 

Case 3: location application (like PCFriendly) reads BCA 
information and acts upon predefined information in the 
BCA number itself. This case does not necessarily require an 
Internet connection. The BCA is obtained utilizing ASPI 
code to read the 188 bytes of information. 
Examples of Cases: 

Case 1: ActiveX control is designed using C++ and 
embedded in HTML page (using standard OBJECT defini- 
tion in HTML). When the web page is loaded, so is the 
ActiveX control. Upon a grant of permission by a consumer, 
the ActiveX control accesses the DVD-ROM drive, obtains 
BCA data, and any other pertinent information. The ActiveX 
control then "posts" this information to the web server using 
HTTP or FTP POST methods. The web server automatically 
reads and parses the POST information, and acts upon this 
information (for example, by sending the consumer to a 
unique URL that is only accessible if the correct DVD with 
the correct BCA is in the DVD-ROM drive). 

Case 2: Local C++ application (PCFriendly) utilizes a 
remote agent technology developed by InterActual. The 
remote agent technology automatically connects to the 
remote web server (without consumer interaction) and 
passes the web server the BCA number with any other 
pertinent information. The remote agent also supports HTTP 
or FTP POST methods. The web server automatically reads 
and parses the POST information, and acts upon this infor- 
mation. 

Examples Include: 

Consumer request to purchase a specific product is auto- 
matically routed to the retailer from which the original DVD 
was purchased. In support of this example, a virtual POP/ 
MDF display and information is downloaded (or unlocked) 
locally and presented to consumer. 

Case 3: Local C++ application or activeX controls in a 
local web page access the BCA information on the DVD. 
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Based on this information, the local application acts upon 
this information. (In this mode, the information contains in 
the BCA field must have sufficient information for local 
application to act upon). 

The current system involves an online database that S 
provides a real-time lookup based on the BCA. The resulting 
lookup in the database can retrieve information specific to 
the application such as a consumer profile, retailer and 
support location and piracy information. 

USAGES OF BCA INFORMATION 10 
Retail Distribution 

When a remote agent connects to a server with BCA 
information, the server performs a real-time lookup on the 
BCA number and determines the replicator, distributor, 15 
and/or retailer for the passed BCA number. This information 
can then be used for various projects, such as Updating or 
changing channel/banner/programming in PCFriendly soft- 
ware. FIG. 2 depicts this operation as a RemoteSync 238. 
Unlock specific assets such as HTML, video, graphics and 2Q 
others which are depicted in function block Unlock Server 
230. Play different assets or portion of video based on BCA 
information as shown in function block Unlock Server 230. 
The application also downloads new content based on the 
BCA information RemoteSync 238. 25 

The BCA information can also be utilized to direct 
e-commerce transactions or "buy-me" buttons to an appro- 
priate retailer utilizing the RemoteTrak/BCATrak function 
234. 

An application in accordance with a preferred embodi- 3Q 
ment can also broadcast new information/updates as shown 
in the Broadcast Server function block 236. Logic is also 
provided to unlock and/or control access to specific web 
sites based on BCAinformation as shown in the RemoteTrak 
Server function block 230. This logic provides consumer 35 
redirect to specific "storefront" of a retailer. 

Track Individual Retail Store Performance 

Specific retail store performance and consumer online 
usage associated with specific retailers can be tracked uti- 40 
lizing information based on the BCA number. This provides 
a local retailer with information to determine the most 
successful opportunities to get users online. Information 
such as a virtual Point of Purchase (POP) and Marketing 
Development Fund (MDF) utilize the BCA information and 45 
the RemoteTrak Server function 230 to track and attract 
consumers. 

Discount coupons and the like (e.g., "cents ofF' coupons, 
rebate coupons, special offer coupons, or the like, collec- 
tively referred to herein as "coupons") have become an 50 
integral part of marketing strategies for many products, 
particularly retail consumer goods, sundries, foodstuffs, 
hardware, clothing, and the like, typically sold at local 
grocery, drug, and discount stores. Product manufacturers 
have come to rely upon coupons, rebate and gift certificates 55 
or the like to promote new and existing products, boost sales, 
and obtain demographic information concerning consumer 
buying patterns. Consumers have come to rely upon cou- 
pons or certificates as a technique for reducing costs. 

Prior art couponing techniques have had several 60 
disadvantages, not the least of which are low response rate 
and fraud. In the prior art, coupons may be distributed using 
direct mailing techniques, printed in newspapers, 
magazines, or the like, distributed with other commercial 
goods (e.g., laundry soap coupon packaged with washing 65 
machine), or distributed (e.g., by original equipment manu- 
facturers or OEMs) with the same or like goods, computers 



420 Bl 

16 

or the like (e.g., "cents off toward next purchase). Such 
techniques require massive amounts of printing and 
distribution, and historically have a low response rate (e.g., 
typically less than 2% of coupons distributed are redeemed). 
Thus, such mass-distribution techniques may not be cost 
effective, and are not environmentally friendly, due to the 
large amount of paper wasted. 

Such low response rates may be due in part to the 
difficulty a consumer may have in maintaining, cataloging, 
and finding appropriate coupons before shopping. A particu- 
lar consumer may have at his or her disposal only those 
coupons that have been sent to him or her and have been 
retained by the consumer. Moreover, since many coupons 
have expiration dates, a consumer may have to carefully 
catalog each coupon to insure that it is redeemed before such 
an expiration date occurs. Such techniques are time- 
consuming and cumbersome. Generally, only those consum- 
ers on a budget or those who use couponing as a hobby have 
sufficient time to maximize their use of available coupons. 
Busier and more affluent consumers may not believe that 
such coupon management techniques are cost effective. This 
latter group of consumers may represent a more desirable 
demographic for a product manufacturer to attract or track. 

With the advent of double or even triple redemption 
couponing promotions provided by some retail stores (e.g., 
grocery store chain or the like) as well as generous cash 
rebate coupon promotions (i.e., gift certificates or the like), 
fraud had become an every increasing problem in coupon 
marketing. Color photocopiers may create coupons that are 
indistinguishable from originals. Unscrupulous consumers 
may use such copied coupons to purchase large numbers of 
items at reduced prices or fraudulently obtain rebates for 
products which were never purchased. 

Moreover, some unscrupulous retailer may conspire with 
coupon brokers to redeem large numbers of illicitly obtained 
or generated to defraud manufacturers. 

As coupon discounts or rebates may be used for promo- 
tional purposes, the resulting net price to the consumer with 
such a discount may be less than the product manufacturer's 
wholesale price. A product manufacturer may offer such 
steep discounts in the hope of obtaining future sales at full 
retail prices. If a consumer uses a photocopied coupon for 
multiple purchases of a retail item, the product manufacturer 
may not obtain the desired repeat sales at full retail price, 
and the entire scheme of couponing may be defeated. 

In addition, prior art couponing techniques have yielded 
little, if any, useful data to product manufacturers regarding 
who is redeeming such coupons. Consumer demographic 
data is invaluable to a product manufacturer in determining 
which products to target to particular consumer groups (e.g., 
through particular advertising venues). Moreover, such 
demographic data may be used to more efficiently distribute 
future coupons. In addition, information as to the buying 
habits (i.e., recency, frequency, and monetary value or RFM) 
and demographics of particular consumers or groups of 
consumers have a market value and such information may 
be sold or traded for a profit. 

Various techniques have been tried to eliminate or reduce 
fraud, provide more convenient techniques for distributing 
coupons, and to better track consumer demographic data. De 
Lapa et al., U.S. Pat. No. 5,353,218 discloses a focused 
coupon system. FIG. 6 of De Lapa et al. is most illustrative. 
De Lapa et al. discloses a system for distributing coupons 
with a machine readable code (barcode) containing both 
customer and coupon identifications. The consumer code 
may be replaced with a generic code used in a look-up table 
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for coupon veriflcation and information. The entire 
machine-readable code may be captured and uploaded to a 
central database for determining coupon and consumer 
identification. The uploaded information may be used for 
marketing purposes (to determine which coupons to next 5 
send to the consumer) and/or for rebate purposes. 

Although the system of De Lapa et al. attempts to provide 
a more focused distribution technique, the system still relies 
upon paper coupons being distributed to consumers. Con- 
sumers may throw out such mass mailings (i.e., "junk mail") io 
without opening them. Moreover, the system relies upon the 
consumer supplying demographic information in a question- 
naire or the like in order to be provided with the coupons. 
Moreover, since the coupons of De Lapa et al. are 
preprinted, coupon trading or copying may be more preva- 15 
lent. 

Furthermore, in De Lapa et al., no mechanism is present 
for capturing subsequent demographic information. Id 
addition, as consumer data is captured at the store level, an 
additional mechanism may be required to upload such 20 
consumer information to a centralized database to capture 
consumer demographic information. Additional data pro- 
cessing hardware/software may be required at a retail store 
in order to process such data. Thus, retailers may be initially 
reluctant to invest in such a scheme. 25 

In retailing, it may be essential to check out consumers in 
as little time as possible. Thus, if additional processing time 
is required during customer checkout to process the coupons 
of De Lapa et al. retailers may be less likely to accept adopt 
such technologies. 

Moreover, under the scheme of De Lapa et al., there is no 
mechanism provided to insure that the individual who 
receives the coupons is the targeted individual. If a con- 
sumer moves to a new address, new occupants at the old 35 
address may receive and redeem coupons addressed to the 
consumer. Thus, target tracking data may be inaccurate or 
incomplete. 

Murphy, U.S. Pat. No. 5,305,195, issued Apr. 19, 1994, 
discloses an interactive advertising system for on-line ter- 40 
annals. A series of remote terminals receive compressed and 
encoded video advertising signals that may be stored on an 
internal hard drive. The advertising videos are played, and a 
consumer may select products using the terminal. In FIG. 4, 
(Col. 7, lines 45-50) Murphy discloses that a printer may be 45 
provided for printing selected coupons. 

The apparatus of Murphy may solve some of the problems 
associated with distributing coupons in paper form. 
However, The Murphy system appears to be more concerned 
with directing advertising information than collecting demo- 50 
graphic information or distributing coupons. Thus, it does 
not appear that the apparatus of Murphy is equipped to 
process demographic information or reduce coupon fraud. 
Moreover, Murphy discloses his apparatus for use in college 
campuses, a limited and narrow consumer demographic. 55 

Von Kohorn, U.S. Pat. No. 5,128,752, issued Jul. 7, 1992 
discloses a system and method for generating and redeeming 
tokens selected from television data. Product information 
and authentication data may be transmitted and displayed on 
a television and a home printer. A viewer may select a 60 
coupon for printing and redeem the coupon at a retail store. 
Von Kohorn does disclose a technique for reducing fraud 
(Col. 7, lines 16-38). However, it appears that these tech- 
niques require action at the retail level to verify that a 
coupon is indeed legitimate, including, in one embodiment, 65 
requesting identification credentials from the consumer. 
Such techniques may be intrusive and cumbersome to use in 
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a retail establishment where a number of coupons may be 
redeemed at any given time. 

Moreover, it does not appear in the system of Von Kohorn, 
which relies on broadcasting, does not target specific con- 
sumers with particular coupons. Rather, it appears that the 
coupons are distributed to all viewers equipped with the 
appropriate apparatus. Note that in FIG. 6 (Col. 9, lines 
40-4S) Von Kohorn discloses a technique for recording 
marketing data from consumer information encoded into the 
coupon. 

Axler et al., U.S. Pat. No. 5,305,197, issued Apr. 19, 1994, 
discloses a coupon-dispensing machine with feedback. A 
consumer kiosk is placed in a retail establishment or the like 
to display advertising (LED scroll) and allow customers to 
print out selected coupons. A proximity sensor detects the 
presence of customers near the apparatus. 

The Axler device may solve some of the problems asso- 
ciated with paper distribution of coupons. However, it does 
not appear that the Axler device may retrieve any significant 
amount of consumer demographic data other than the num- 
ber and type of coupons printed. Moreover, within the 
in-store environment, it may be difficult to enter such 
consumer data, particularly with the keypad disclosed by 
Axler. Thus, it does not appear that the Axler device may be 
suitably adapted to retrieve consumer demographic data. 

A fundamental fault with the Axler device is that it does 
not appear to target or prior motivates customers with to visit 
a retailer with specific coupons. Rather, the in-store location 
of the Axler device may facilitate a consumer "targeting" a 
coupon. In other words, a consumer may make a number of 
product selections in a store and then visit the coupon kiosk 
of Axler to determine whether any purchases are subject to 
coupon discount or rebate. Thus, the fundamental goal of 
couponing— to motivate a consumer to purchase a product- 
may be compromised. 

In addition, the kiosk of Axler may occupy valuable 
commercial retail space. In a retail store (e.g., supermarket 
or the like) even a few feet of shelving may be extremely 
valuable for displaying and containing retail merchandise. 
Product manufacturers may even pay "rent" to a retail 
establishment in the form of rebates or promotional fees in 
order to obtain prominent shelf space. Thus, a retail estab- 
lishment may be loath to give up such valuable space to a 
couponing kiosk. Moreover, it may be time consuming and 
frustrating for customers waiting in line to access the kiosk. 
Providing additional kiosks may be cost-prohibitive. 

Support Services in Accordance with a Preferred 

Embodiment 

To provide enhanced support for DVD in a commercial 
environment, the BCA is utilized to redirect to a specific 
support site based on table lookup utilizing the BCA number 
as shown in FIG. 2 at function block 234 RemoteTrak/ 
BCATrak Server function block. Logic is also provided to 
track disc anomalies and defects from manufacturing pro- 
cess as shown in function block 234 RemoteTrak/BCATrak 
Server. Other logic is also provided to track retailer-specific 
support issues as shown in function block 234 RemoteTrak/ 
BCATrak Server, to track geographical support issues as 
shown in function block 234 RemoteTrak/BCATrak Server, 
to restrict access to support sites based on BCA information 
as shown in function block RemoteTrak/BCATrak Server 
234. Finally, enhanced support is provided for broadcast 
updates utilizing support and drivers based on BCA infor- 
mation as shown at function block 236 Broadcast Server. 

Security in Accordance with a Preferred 
Embodiment 

The BCA information can also be combined with game 
unlocking logic to provide an authorized user with unlocked 
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video based on BCA information as shown at function block 
238 DVDUnlock Server. BCA information has a unique 
identifier which, when combined with other data, can track 
when a movie and/or a game was given to a friend which 
will trigger another transaction for payment or other infor- 5 
mation as shown in function block 234 RemoteTrak/ 
BCATrak Server. This information can also be used to track 
pirated DVDs, and report the information back to the retailer 
as shown in function block 230 

RemoteTrak/BCATrak Server, back to a manufacturer as 10 
shown in function block 230 RemoteTrak/BCATrak Server 
and back to a distributor as shown in function block 230 
RemoteTrak^CATrak Server. 

This capability provides the ability to localize pirated 
discs to a specific region/retailer as shown in function block 15 
230 RemoteTrak/BCATrak Server and track illegal region 
code use and potentially trace back to retailer/distributor as 
shown in function block 230 RemoteTrak/BCATrak Server. 



General/Advertising Logic in Accordance with a 
Preferred Embodiment 

Logic is also provided to tailor video based information as 
part of the BCA (play video 1 for one demographic, play 
video 2 for another as shown in unction block 238 DVDUn- 
lock Server, RemoteSync, and to tailor internet/browser 
experience based on BCA information as shown in function 
block 238 RemoteTrak/BCATrak Server. Targeted advertis- 
ing is also provided based on BCA information and content 
can be tailored for channel/banner/programming within 
PCFriendly software) based on consumer profile which is 
associated with BCA as shown in function block 238 
RemoteSync. 

FIG. 5 is a block diagram of a user experience in 
accordance with a preferred embodiment. The BCA number 
503 is burned/added onto DVD 505. When the DVD is 
placed into a consumer's computer 510, InterActual's soft- 
ware automatically reads the BCA number and passes this 
information to the web server. The BCA information is 
passed to the web server, running an IS API extension 540, 
using either HTTP or FTP protocol 515. The information can 
be passed from a local "client" application, or an applet or 
ActiveX-type control can be downloaded from a web site 
that passed this information to the web server. The infor- 
mation is currently passed using an HTTP POST command 
using the syntax shown below. 

http://www.pcfriendly.com/scripts/ 
RemoteAgentUpgrade.DLL&bca = 
1234568790?userid=12 34568790?. . . 

The current implementation of the web server is an ISAPI 
extension written in Visual C++ and is currently named 
RemoteAgentUpgrade.DLL for use with Microsoft Win- 
dows NT. Upon receiving the POST command, the ISAPI 
extension parses the information in the POST command to 
determine the BCAnumber and other associated information 
(such as user ID, etc.). This information is then logged in the 
web server log table 530, and is used to query specific 
information in the web server database 550 based on the 
POST. This flexible database structure enables a variety of 
uses of the BCA number. 

A retailer example in accordance with a preferred embodi- 
ment is presented to assist one of ordinary skill in the art to 
make and use the invention without undue experimentation. 
A consumer inserts a DVD into their DVD-ROM drive. The 
consumer is presented with an HTML page with a "Buy- 
Me" button. Upon clicking the Buy-Me button, the con- 
sumer is connected to the Internet to a specific web page that 
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includes an ActiveX control. The ActiveX control automati- 
cally connects to the ISAPI extension with BCA information 
for the currently inserted DVD. The ActiveX control also 
informs the ISAPI extension that the consumer is attempting 
an e -commerce transaction. The ISAPI extension parses the 
information from the POST command, and connects to the 
web server database. Since the ActiveX control informed the 
ISAPI extension that an e-commerce transaction is being 
attempted, the ISAPI extension connects to the web server 
database to determine the retailer from which the DVD was 
originally purchased. This can be determined because a web 
server database contains a BCA lookup table 560 with three 
fields: 



BCA Number 
DVD Title Name 
Retailer/Store 



#123458790 
Lost In Space 

Hollywood Video, Store #23 



Using the Retailer/Store information, the appropriate 
e-commerce URL can be determined from Retailer table 570 
that contains information specific for that Retailer: 



Retailer/Store 

E- Commerce URL 



Hollywood Video, Store #23 
http://www.retailer23.com/. . 



FIG. 6 is a flowchart of a redirect operation for an 
electronic commerce transaction utilizing BCA information 

30 for intelligent processing in accordance with a preferred 
embodiment Processing commences at 600 when a user 
inserts a DVD into a player and the electronic commerce 
operation is initiated by a user action as shown in function 
block 610. When the user selects the purchase option at 610, 

35 logic is initiated to read the BCA information and this 
information is combined with other user information from 
the server database as shown in function block 620. Then the 
server performs a table lookup to ascertain the retailer that 
sold the original DVD as shown in function block 630. The 

40 original retailer becomes the target for the purchase that the 
user initiated in function block 610, and the e-commerce 
transaction is re-routed to the retailer that sold the disk as 
shown in function block 640. Finally, a transaction is posted 
to the server database that memorializes the events associ- 

45 ated with the re -direct operation. 

FIGS. 7Aand 7B are flowcharts setting forth the detailed 
logic associated with user connection and update for DVD 
processing in accordance with a preferred embodiment. 
Processing commences when a user connects to the Internet 

50 with a DVD application active as illustrated in function 
block 700. The remote agent detects the live internet con- 
nection and connects the application to a server for further 
processing as shown in function block 710. Then, the server 
connects the application with the appropriate version iden- 

55 tification and upgrades the remote application if an upgraded 
version is available without further input from the user as 
shown in function block 720. If the user is a first time user, 
then the server obtains user information from the user 
utilizing, for example data from the DVD, or a query 

60 operation as shown in function block 730. Then, the appli- 
cation collects current DVD usage information and logs the 
information to a database as shown in function block 740. 
Finally, the current DVD information is transmitted to the 
user as shown in function block 750. Processing is then 

65 transferred to function block 752 of FIG. 7B where the 
application determines if any broadcast events are available. 
Then, in function block 754, if a user requests broadcast 
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events, then the server passes the information to the user in 
HTTP format as shown in function block 756. The remote 
agent receives the information from the server and coverts 
the information for the particular DVD player as shown in 
function block 758, and ultimately logs user information in 5 
a database at the server as shown in function block 760. 

General Advertising Flows 

FIG. 8 is a flowchart settiDg forth the detailed logic for 
general advertising services in accordance with a preferred 10 
embodiment. The flowchart illustrates the detailed logic 
associated with presenting advertising (such as a banner) 
customized for a particular distributor/retailer/etc. 

FIG. 8 presents logic demonstrating the display of specific 
advertising information based on a retailer/distributor uti- 15 
lizing BCA information for intelligent processing in accor- 
dance with a preferred embodiment. Processing commences 
at 800 when a user inserts a DVD with BCAinformation into 
a player, and the advertising operation is initiated by a user 
action as shown in function block 810. When a user connects 20 
to a web page on the Internet at 810, logic is initiated to read 
the BCA information and this information is combined with 
other user information from the server database as shown in 
function block 820. Then the server performs a table lookup 
to ascertain the retailer that sold the original DVD as shown 25 
in function block 830. Once the original retailer is 
ascertained, the server performs another table lookup to 
determine the advertising banner as shown in function block 
840. The advertising banner associated with original retailer 
is then displayed in the web site 810 as shown in function 30 
block 850. Finally a transaction is posted to the server 
database that memorializes the events associated with the 
advertising operation 860. 

Distributors, retailers, computer or other hardware ^ 
manufacturers, direct sales people, content developers or 
anyone who distributes, sells, or gives away DVDs will all 
receive benefits as detailed below in accordance with a 
preferred embodiment. Some of these include for example: 

Blockbuster, DVDExpress, Amazon.com, Best Buy, 40 
Deluxe, Technicolor/Ninbusl, IBM, Gateway, Dell, Creative 
Labs, New Line, Warner, Activision, Electronic Arts, Gen- 
eral Motors and Ford Motor Company. 

FIG. 9 is a flowchart demonstrating the display of specific 
advertising information based on genre/type of DVD utiliz- 45 
ing BCA information for intelligent processing in accor- 
dance with a preferred embodiment. Processing commences 
at 900 when a user inserts a DVD with BCAinformation into 
a player, and the advertising operation is initiated by a user 
action as shown in function block 910. When the user 50 
connects to web page on the Internet at 910, logic is initiated 
to read the BCA information and this information is com- 
bined with other user information from the server database 
as shown in function block 920. Then the server performs a 
table lookup to ascertain the title and genre of the DVD as 55 
shown in function block 930. Once the title and genre is 
ascertained, the server performs another table lookup to 
determine the advertising banner as shown in function block 
940. The advertising banner associated with the title and 
genre of the DVD is then displayed in the web site 910 as $0 
shown in function block 950. Finally a transaction is posted 
to the server database that memorializes the events associ- 
ated with the advertising operation 960. 

FIG. 10 is a flowchart of a download operation for 
downloading and updating retailer-specific information of 65 
the DVD utilizing BCA information for intelligent process- 
ing in accordance with a preferred embodiment. Processing 
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commences at 1000 when a user connects to the Internet 
with a DVD application active. Logic detects a live Internet 
connection, reads the BCA information, and initiates a 
connection to the server as shown in function block 1010. 
After logic initiates the connection to the server in 1010, the 
DVD application requests alt available downloads from the 
server for the retailer of the currently inserted DVD, as 
shown in function block 1020. The server performs a table 
lookup to ascertain the retailer that sold the original DVD as 
shown in function block 1030. Then the server performs 
another table lookup to determine the download information 
as shown in function block 1040. Once the download 
information is determined for the request initiated by the 
application in function block 1020, the server passes the 
download information to the application using HTTP pro- 
tocal as shown in function block 1050. Finally a transaction 
is posted to the server database that memorializes the events 
associated with the download operation 1060. 

FIG. 11 is a flowchart of a download operation for 
downloading and updating DVD title-specific information 
utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment. Processing com- 
mences at 1100 when a user connects to the Internet with a 
DVD application active. Logic detects a live Internet 
connection, reads the BCA information, determines DVD 
application version information, and initiates a connection to 
the server as shown in function block 1110. After logic 
initiates the connection to the server in 1110, the DVD 
application requests all available downloads from the server 
for the currently inserted DVD title, as shown in function 
block 1120. The server performs a table lookup to ascertain 
the DVD title as shown in function block 1130. Then the 
server performs another table lookup to determine the down- 
load information as shown in function block 1140. Once the 
download information is determined for the request initiated 
by the application in function block 1120, the server passes 
the download information to the application using HTTP 
protocal as shown in function block 1150. Finally a trans- 
action is posted to the server database that memorializes the 
events associated with the download operation 1160. 

FIG. 12 is a flowchart of a tailored video viewing opera- 
tion utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment. Processing com- 
mences at 1200 when a user inserts a DVD into a player and 
video playback is initiated by a user action as shown in 
function block 1210. When the user selects the play video 
option at 1210, logic is initiated to read the BCAinformation 
and this information is combined with other user informa- 
tion from the server database as shown in function block 
1220. The server performs a table lookup to ascertain the 
retailer that sold the original DVD as shown in function 
block 1230. Then the server performs another table lookup 
to determine the correct retailer video to play as shown in 
function block 1240. Once the retailer video information is 
determined for the request initiated by the application in 
function block 1210, the server initiates playback of the 
correct video for the retailer that sold the disk as shown in 
function block 1250. Finally a transaction is posted to the 
server database that memorializes the events associated with 
the video viewing operation operation 1260. 

FIG. 13 is a flowchart of a tailored video viewing opera- 
tion utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment. Processing com- 
mences at 1300 when a user inserts a DVD into a player and 
video playback is initiated by a user action as shown in 
function block 1310. When the user selects the play video 
option at 1310, logic is initiated to read the BCAinformation 
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and this information is combined with other user informa- 
tion from the server database as shown in function block 
1320 and transmitted to the server. The server performs a 
table lookup to ascertain the genre and/or title as shown in 
function block 1330. Then the server performs another table 
lookup to determine the correct genre and/or title video to 
play as shown in function block 1340. Once the genre and/or 
title video information is determined for the request initiated 
by the application in function block 1310, the server initiates 
playback of the correct video for the genre and/or title as 
shown in function block 1350. Finally a transaction is posted 
to the server database that memorializes the events associ- 
ated with the video viewing operation operation 1360. 

FIG. 14 is a flowchart of the logic associated with a 
tailored multimedia viewing operation utilizing BCA infor- 
mation for intelligent processing in accordance with a pre- 
ferred embodiment. Processing commences at 1400 when a 
user inserts a DVD into a player and view is initiated by a 
user action as shown in function block 1410. When the user 
selects the view option at 1410, logic is initiated to read the 
BCA information as shown in function block 1420. The 
DVD application performs a local table lookup to ascertain 
the genre/title/retailer as shown in function block 1430. 
Then the DVD application performs another local table 
lookup to determine the correct multimedia element to 
display as shown in function block 1440, Once the multi- 
media element is determined for the request initiated by the 
application in function block 1410, the DVD application 
initiates playback of the correct mutlimedia element for the 
genre/title/retailer as shown in function block 1450. Finally 
a transaction is posted to the server database that memori- 
alizes the events associated with the multimedia viewing 
operation 1460. 

Flowcharts for Security Processing in Accordance 
with a Preferred Embodiment 

FIG. 15 is a flowchart of a security operation for restrict- 
ing access to specific web sites utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment. Processing commences at 1500 when a user 
inserts a DVD into a player and the security operation is 
initiated by a user action as shown in function block 1510. 
When the user initiates connection to a secure web site at 
1510, logic is initiated to read the BCA information and this 
information is combined with other user information from 
the server database as shown in function block 1520. Then 
the server performs a table lookup to ascertain if the user, 
based on the BCA number, is allowed access to the secure 
web site as shown in function block 1530. The server either 
allows or restricts entry to the web site based on the BCA 
number as shown in function block 1540. Finally a trans- 
action is posted to the server database that memorializes the 
events associated with the security operation 1550. 

FIG. 16 is a flowchart of a unlock operation for an 
electronic commerce transaction utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment. Processing commences at 1600 when a user 
inserts a DVD into a player and the unlock operation is 
initiated by a user action as shown in function block 1610. 
When the user selects the play/install DVD option at 1610, 
logic is initiated to read the BCA information and this 
information is combined with other user information from 
the server database as shown in function block 1620. Then 
the server performs a table lookup to ascertain if the DVD 
can be unlocked for playing or installation as shown in 
function block 1630. If the server determines that the user 
must first perform a purchase transaction, the server prompts 
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the user for any necessary transaction information as shown 
in function block 1640. After the user completes the trans- 
action in function block 1640, or the server determines that 
a transaction occurred at an earlier time, or if the server 
5 determines that a transaction does not need to occur, the 
server performs the unlock operation as shown in function 
block 1650. Finally a transaction is posted to the server 
database that memorializes the events associated with the 
unlock operation 1660. 

30 FIG. 17 is a flowchart of an unlocking operation for an 
electronic commerce transaction utilizing BCA information 
for intelligent processing in accordance with a preferred 
embodiment. Processing commences at 1700 when a user 
inserts a DVD into a player and the unlock operation is 

15 initiated by a user action as shown in function block 1710. 
When the user selects the play/install DVD option at 1710, 
logic is initiated to read the BCA information and this 
information is combined with other user information from 
the server database as shown in function block 1720. The 

20 server performs a table lookup to ascertain the user infor- 
mation for the DVD using the BCA information as shown in 
function block 1730. Then the server performs a table 
lookup to ascertain if the DVD can be unlocked for playing 
or installation as shown in function block 1740. If the server 

25 determines that the user must first perform a purchase 
transaction, the server prompts the user for any necessary 
transaction information as shown in function block 1750. 
After the user completes the transaction in functional block 
1750, or if the server determined that a transaction occurred 

30 at an earlier time, or if the server determines that a trans- 
action does not need to occur, the server performs the unlock 
operation as shown in function block 1760. Finally a trans- 
action is posted to the server database that memorializes the 
events associated with the unlocking operation 1770. 

35 FIG. 18 is a flowchart of a logging operation for tracking 
piracy and misuse of a DVD utilizing BCA information for 
intelligent processing in accordance with a preferred 
embodiment Processing commences at 1800 when a user 
inserts a DVD into a player and the logging operation is 

40 initiated by a user action as shown in function block 1810. 
When the user user selects the play/install DVD option at 
1810, logic is initiated to read the BCA information and this 
information is combined with other user information from 
the server database as shown in function block 1820. The 

45 server performs a table lookup to ascertain if the user, based 
on the BCA number, is allowed to apply or install the DVD 
as shown in function block 1830. Then the server either 
enables or disables the DVD for playback/installation as 
shown in function block 1840. Finally a transaction is posted 

50 to the server database that memorializes the events associ- 
ated with the logging operation 1850. The logging informa- 
tion can be used to localize pirated discs to a specific region, 
track illegal region code use, and trace misuse/pirated DVDs 
back to retailer, distributor, manufacturer, or content devel- 

55 oper. 

Support Services 

FIG. 19 is a flowchart of a redirect operation for a support 
transaction for intelligent processing in accordance with a 

60 preferred embodiment. Processing commences at 1900 
when a user inserts a DVD with BCA information into a 
player, and the redirect operation is initiated by a user action 
as shown in function block 1910. When the user selects the 
support option at 1910, logic is initiated to read the BCA 

65 information and this information is combined with other 
user information from the server database as shown in 
function block 1920. Then the server performs a table 
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lookup to ascertain the support organization for the original 
DVD as shown in function block 1930. The support orga- 
nization becomes the target for the support request that the 
user initiated in function block 1910, and the support trans- 
action is re-routed to the support organization associated 5 
with the DVD in function block 1940. Finally a transaction 
is posted to the server database that memorializes the events 
associated with the redirect operation 1950. 

FIG. 20 is a flowchart of a display operation for a support 
transaction for intelligent processing in accordance with a 10 
preferred embodiment. Processing commences at 2000 
when a user inserts a DVD with BCA information into a 
player, and the display operation is initiated by a user action 
as shown in function block 2010. When the user selects the 
support option at 2010, logic is initiated to read the BCA 
information and this information is combined with other 15 
user information from the server database as shown in 
function block 2020. Then the server performs a table 
lookup to ascertain the DVD -specific support information 
for the DVD in the user's player as shown in function block 
2030. Once the server has determined the DVD -specific 20 
information for the support request initiated by the user in 
function block 2010, the DVD-specific information is dis- 
played to the user in function block 2040. Finally a trans- 
action is posted to the server database that memorializes the 
events associated with the display operation 2050. 25 

FIG. 21 is a flowchart of support tracking utilizing BCA 
for intelligent processing in accordance with a preferred 
embodiment. Processing commences at 2100 when a user 
inserts a DVD with BCA information into a player, and the 
display operation is initiated by a user action as shown in 30 
function block 2110. When the user selects the support 
option at 2110, logic is initiated to read the BCA information 
and this information is combined with other user informa- 
tion from the server database as shown in finction block 
2120. Then the server performs a table lookup to ascertain 35 
the DVD -specific support information for the DVD in the 
user's player as shown in function block 2130. Once the 
server has determined the DVD -specific information for the 
support request initiated by the user in function block 2110, 
the DVD-specific information is used, for example, to track 40 
retailer-specific support issues or geographical support 
issues as shown in function block 2140. Finally a transaction 
is posted to the server database that memorializes the events 
associated with the display operation 2150 and the memo- 
rialized information is utilized to generate reports tracking 45 
retailer-specific support issues or geographical support 
issues. 

FIG. 22 is a flowchart of a redirect operation for a support 
transaction for intelligent processing in accordance with a 
preferred embodiment. Processing commences at 2200 50 
when a user inserts a DVD with BCA information into a 
player, and the redirect operation is initiated by a user action 
as shown in function block 2210. When the user selects the 
support option at 2210, logic is initiated to read the BCA 
information and this information is combined with other 55 
user information from the server database as shown in 
function block 2220. Then the server performs a table 
lookup to ascertain the support organization for the original 
DVD as shown in function block 2230. The support orga- 
nization becomes the target for the support request that the 60 
user initiated in function block 2210, and, if allowed, the 
support transaction is re-routed to the support organization 
associated with the DVD in function block 2240, Otherwise, 
the user is redirected to a location informing the user that 
support location is not available. Finally a transaction is 65 
posted to the server database that memorializes the events 
associated with the redirect operation 2250. 



FIG. 23 is a flowchart of a broadcast operation for 
downloading update, support and application information 
utilizing BCA information for intelligent processing in 
accordance with a preferred embodiment. Processing com- 
mences at 2300 when a user connects to the Internet with a 
DVD application active. Logic detects a live Internet 
connection, reads the BCA information, determines DVD 
application version information, and initiates a connection to 
the server as shown in function block 2310. After logic 
initiates the connection to the server in 2310, the DVD 
application requests all broadcast information from the 
server for the the DVD, as shown in function block 2320. 
The server performs a table lookup to ascertain the broadcast 
information for the DVD as shown in function block 2330. 
Once the broadcast information is determined for the request 
initiated by the application in function block 2320, the server 
passes the broadcast information to the application using 
HTTP protocal as shown in function block 2340. Then the 
DVD application acts upon the broadcast information by 
either presenting information to the user or automatically 
acting upon the information as shown in function block 
2350. Finally a transaction is posted to the server database 
that memorializes the events associated with the download 
operation 2360. The e-commerce URL is then returned to the 
ActiveX control so that the consumer's purchase request can 
be redirected to the appropriate URL. 

Visual C++ code in accordance with a preferred embodi- 
ment is provided below to further embellish the description 
of the invention. * These functions are used to obtain BCA 

information * * DATE NAME REASON * * 

Mar. 22, 1999 111 Created * * NOTES: * * © COPYRIGHT 
1999 InterActual Technologies, Inc. ALL RIGHTS 
RESERVED . #include "stdafx.h"#include 
"scsidefe.h"#include "wnaspi32. h"DWORD xReportBCA 
(LPBYTE pbData, WORD cbData); DWORD 
AtapiSendCommand(LPBYTE pPacket, LPBYTE pBuffer, 
DWORD cbBuffer); DWORD Atapilnit(int index); void 
AtapiUninito; DWORD xReportBCA(LPBYTE pbData, 
WORD cbData) DWORD nRetura; UCHAR Cdb[16]; 

DWORD bWindowsNT FALSE; 

OSVERSIONINFO vi; 

vi.dwOSVersionlnfoSize =sizeof(vi); 

if (GetVersionEx(&vi)) bWindowsNT 
=(vi.dwPlatformld-»VER_PIATFORM_WIN32_NT); 

if (bWindowsNT) return FALSE; II for now not imple- 
mented 

ZeroMemory(&Cdb ^izeof (Cdb)); 

Cdb[0] =OxAD; // CMD_READ_DVD_STRUC; 

Cdb[7] =0x03; // Format Cdb[8] =HIBYTE(cbData); // 
sizeof AllocationLength Cdb[9] =LOBYTE(cbData); // 
sizeof AllocationLength Cdb[10] -0; // Agid nReturn 
«AtapiSendCommand(Cdb, pbData, cbData); 

return nReturn; typedef DWORD (_cdecl 
*LPFNSENDASPI32COMMAND)(LPSRB); typedef 
DWORD (_cdecl * LPFNGETASPI32SUPPORTINFO) 
(VOID); BOOL AspilnquiryCmd(BYTE *pbinq, WORD 
cbData); // statics yuk static BYTE AdapterCountoO; static 
BYTE AdapterID-0; static BYTE TargetID=0; 
LPFNSENDASPI32COMMAND 
g fnSendASPI32Command -NULL; 
LPFNGETASPI32SUPPORTINFO 
g fnGetASPI32SupportInfo -NULL; HINSTANCE 
g_hWNASPI-NULL; DWORD Atapilnit(int index) { if 
(g_fnSendASPI32Command && 
g_fnGetASPI32Supportlnfo) return TRUE; 
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if (!(g_hWNASPI ~LoadLibrary("WNASPI32. DLL"))) 
return FALSE; 

if (NULL = = (g_fnSendASPI32Command 
~(LPFNSENDASPI32COMMAND) GetProcAddress 
(ghWNASPI, "SendASPI32Command"))) return FALSE; if * 
(NULL «o(g fnGetASPI32SupportInfo 

-(LPFNGETASPI32SUPPORTINFO) etProcAddress 
(g_hWNASPI, "GetASPI32Supportlnfo"))) return FALSE; 
DWORD ASPI32Status =(*g_fEGetASPI32SupportInfo)0; 
AdapterCount «(LOBYTE(LOWORD(ASPI32Status))); if 10 
((AdapterCount =0) 11 (HIB YTE(LOW ORD 
(ASPI32Status)) i-SS-COMP)) return FALSE; 

BYTE pbInq[LEN-INQUIRY-DATA+l ]; 

for (BYTE aid -0;aid <AdapterCount; aid++) for (BYTE 
tid «0;tid <MAX TARGET; tid++){ AdapterlD =aid; 

TargetID =tid; 

if (AspilnquiryCmd(pblnq ; LEN INQUIRY_DATA)) { if 
(DTYPE_CROM ==pblnq[0]) { if(index~ 0) { return 
TRUE; 20 

return FALSE; } void AtapiUninitO { if (g_hWNASPI) { 
FreeLibrary(gihWNASPI); g_fnSendASPI32Command 
=NULL; 

g_fhGetASPI32SupportInfo -NULL; 

gjhWNASPI -NULL; 

} DWORD AtapiSendCommand(BYTE *pCdb, BYTE 
*pbData, DWORD cbData) { 

PSRB_ExecSCSICmd pSrb«(PSRB_ExecSCSICmd) 
malloc(sizeof(SRB ExecSCSICmd)); 30 

if (pSrb NULL) return FALSE; 

memset(pSrb, 0, sizeof(SRB_ExecSCSICmd)); 

II SendCommand pSrb->SRB Cmd *=SC EXEC SCSI 
CMD; 35 

pSrb->SRB_Status =Oxff; 
pSrb->SRB_HaId -AdapterlD; 

if ((pCdb[0] =«OxA3) && (cbData !=0)) pSrb- 
>SRB_Flags =SRB_DIR_OUT; 

else if(pCdb[0 ]~=0x43) pSrb->SRB_Flags 40 
=SRB_DIR_IN; 

else pSrb->SRB_Flags =SRB_DIR_SCSI; 

pSrb->SRB_Target -TargetID; 

pSrb->SRB_BufLen -(DWORD)cbData; 45 
pSrb->SRB_BufPointer =pbData; 

pSrb->SRB_SenseLen =SENSE_LEN; pSrb- 
>SRB_CDBLen =LEN_ATAPI_PACKET; pSrb- 
>SRB_HaStat *=0xff; pSrb->SRB_TargStat =Oxff; memepy 
(pSrb->CDBByte, pCdb, LEN_ATAPI_PACKET); 50 
DWORD ASPI32Status «(*g_mSendASP]32Command) 
(pSrb); DWORD timeout -600; while ((pSrb->SRB_Status 
SS_PENDING) && (timeout >0)) { Sleep(1 0); timeout--; } 
if (pSrb->SRB_Status — SS COMP){ freefpSrb); return 
TRUE; if ((pSrb->SRB Status==SS ERR) && (pSrb- 55 
>SRB_TargStat-STAXUS" CHKCOND)) { } free(pSrb); 
return FALSE; } BOOL AspilnquiryCmd(BYTE *pblnq, 
WORD cbData) { BYTE Cdb[LEN-ATAPI_PACKET]; 
memset(Cdb, 0, LEN_ATAPI_PACKET); Cdb[0] 
-SCSIJNQ1IRY; Cdb[4] =LENJNQUIRY_DATA; PSR- 60 
B_ExecSCSICmd pSrb =PSRB ExecSCSiCmd)mailoc 
(sizeof(SRB_ExecSCSICmd)); if"(pSrb —NULL) return 
FALSE; memset(pSrb, 0, sizeof(SRB-ExecSCSICmd)); 
pSrb->SRB_Cmd =SC_EXEC_SCSI_CMD; pSrb- 
>SRB_Status -Oxff; pSrb-"^SRB_HaId -AdapterlD; pSrb- 65 
>SRB-Flags =SRB DIR SCSI; pSrb->SRB_Target Tar- 
getID; pSrb->SRB~BufLen -(DWORD)cbData; pSrb- 



>SRB BufPointer =pblnq; pSrb->SRB_SenseLen 
-SENSEJLEN; pSrb->SRB CDBLen -6; pSrb->SRB 
HaStat oOxff; pSrb->SRB-TargStat =Oxff; memcpy(pSrb- 
>CDBByte, Cdb, LEN_ ATAPI ^PACKET) ; // Send Com- 
mand 20 DWORD ASPI32Status 
(*gJfiSendASPI32Command)(pSrb); DWORD timeout 
=600; 1* Wait for pending status */ while ((pSrb->SRB- 
Status -SS-PENDING) && (timeout >0) Sleep(IO); 
timeout-; /* Check Error Code * if (Srb->SRB-Status 
-SS-COMP){ free(pSrb); return TRUE; /* Set last device 
error »/ if ((pSrb->SRB_Status«SS_ERR) && (pSrb- 
>SRB-TargStat==STATUS_CHKCOND)) free(pSrb); 
return FALSE; 

Alternate Embodiments 

It should be noted that varoius permutations of serializa- 
tion may be employed including, but not limited to a 
watermark, hologram, and any other type in substitution or 
combination with the BCA information without diverging 
from the spirit of the claimed invention. 
Watermarking 

Digital video data can be copied repeatedly without loss 
of quality. Therefore, copyright protection of video data is a 
more important issue in digital video delivery networks than 
it was with analog TV broadcast. One method of copyright 
protection is the addition of a "watermark" to the video 
signal which carries information about sender and receiver 
of the delivered video. Therefore, watermarking enables 
identification and tracing of different copies of video data. 
Applications are video distribution over the World-Wide 
Web (WWW), pay-per-view video broadcast, or labeling of 
video discs and video tapes. In the mentioned applications, 
the video data is usually stored in compressed format. Thus, 
the watermark must be embedded in the compressed 
domain. An approach for robust watermarking of MPEG-2 
encoded video is presented in accordance with an alternate 
embodiment. The method is of much lower complexity than 
a complete decoding process followed by watermarking in 
the pixel domain and re-encoding. Although an existing 
MPEG-2 bitstream is partly altered, the method avoids drift 
by adding a drift compensation signal. The method has been 
implemented and the results confirm that a robust watermark 
can be embedded into MPEG-encoded video which can be 
used to securely transmit arbitrary binary information at a 
data rate of several bytes/second. 

The method is easily applicable to other video coding 
schemes like MPEG-1, H.261, and H.263. Digital water- 
marks exist at a convergence point where creators and 
publishers of digitized multimedia content demand 
localized, secured identification and authentication of that 
content. Because existence of piracy is clearly a disincentive 
to the digital distribution of copyrighted works, establish- 
ment of responsibility for copies and derivative copies of 
such works is invaluable. In considering the various forms 
of multimedia content, whether "master/* stereo, NTSC 
video, audio tape or compact disc, tolerance of quality 
degradation will vary with individuals and affect the under- 
lying commercial and aesthetic value of the content. 

It is desirable to tie copyrights, ownership rights, pur- 
chaser information or some combination of these and related 
data to the content in such a manner that the content must 
undergo damage, and therefore a reduction in value, with 
subsequent, unauthorized distribution of the content, 
whether it be commercial or otherwise. Legal recognition 
and attitude shifts, which recognize the importance of digital 
watermarks as a necessary component of commercially 
distributed content (audio, video, game, etc.), will further 
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the development of acceptable parameters for the exchange 
of such content by the various parties engaged in the 
commercial distribution of digital content. 

These parties may include artists, engineers, studios, 
Internet access providers, publishers, agents, on-line service 5 
providers, aggregators of content for various forms of 
delivery, on-line retailers, individuals and parties that par- 
ticipate in the transfer of funds to arbitrate the actual 
delivery of content to intended parties. Since the character- 
istics of digital recordings vary widely, it is a worth while 10 
goal to provide tools to describe an optimized envelope of 
parameters for inserting, protecting and detecting digital 
watermarks in a given digitized sample (audio, video, virtual 
reality, etc.) stream. The optimization techniques described 
hereinafter make unauthorized removal of digital water- 15 
marks containing these parameters a significantly costly 
operation in terms of the absolute given projected economic 
gain from undetected commercial distribution. The optimi- 
zation techniques, at the least, require significant damage to 
the content signal, as to make the unauthorized copy com- 20 
mercially worthless, if the digital watermark is removed, 
absent the use of extremely expensive tools. Presumably, the 
commercial value of some works will dictate some level of 
piracy not detectable in practice and deemed "reasonable" 
by rights holders given the overall economic return. For 25 
example, there will always be fake $100 bills, LEVI jeans, 
and GUCCI bags given the sizes of the overall markets and 
potential economic returns for pirates in these markets — as 
there also will be unauthorized copies of works of music, 
operating systems (Windows 98, etc.), video and future 30 
multimedia goods. However, what differentiates the "digital 
marketplace" from the physical marketplace is the absence 
of any scheme that establishes responsibility and trust in the 
authenticity of goods. For physical products, corporations 
and governments that mark the goods and monitor manu- 35 
facturing capacity and sales to estimate loss from piracy. 
There are also no reinforcing mechanisms, including legal, 
electronic, and informational campaigns to better educate 
consumers. 

With the advent of digital video and digital video 40 
broadcasting, issues of copyright protection have become 
more important, since the duplication of digital video does 
not result in the inherent decrease in quality suffered by 
analog video. One method of copyright protection is the 
addition of a "watermark" to the video signal. The water- 45 
mark is a digital code embedded in the bitstream of the 
digital video that typically identifies the copyright owner. 
The watermark, if applied to individual copies of the video, 
may also be used to identity of the receiver of each copy. 
This processing identifies illegally reproduced copies and 50 
facilitates tracing back to the receiver from which they 
originated. For watermarking of digital video, a number of 
different characteristics of the watermark are desirable. First, 
the watermark should be embedded in such a way that it is 
imperceptible or barely perceptible to a viewer of the video. 55 
Secondly, the watermark should be such that it cannot be 
removed by intentional or unintentional operations on the 
digital video bitstream or on the decoded video without, at 
the same time, degrading the perceived quality of the video 
to the point of significandy reducing its commercial value (a 60 
characteristic referred to as "robustness"). Thirdly, since the 
video may be stored for broadcast in a compressed form 
(such as in a "video-on-demand" server), it is desirable to be 
able to incorporate the watermark into the bitstream without 
having to decode the signal first and to re -encode it after 65 
adding the watermark. This can be accomplished with the 
watermarking of digital still images, but the method used 
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does not lend itself to digital video, due to the additional 
constraints which video signals present. Many digital video 
applications are "constant bit rate" applications, which do 
not tolerate increases in the bit rate of the transmitted 
bitstream. Even in those applications which are not 
restricted to a constant bit rate, unnecessary increases in the 
bit rate should be avoided, so as to preserve the real-time 
decodability of the video signal when transmitted over a 
channel having a given bandwidth. Thus, it is desirable that 
the addition of the watermark does not increase the bit rate 
of the video signal. Past watermarking techniques for digital 
video are limited to the watermarking of uncompressed 
video data. However, since video sequences are often stored 
in a compressed format (thereby saving on memory space), 
watermarking the signal in a way which uniquely identifies 
each receiver of the signal would require decoding of the 
signal, addition of the watermark, and receding before the 
signal is transmitted. This clearly places a significant time 
and processing burden on the task of delivering the video 
sequence. 

Hologram 

Information exchange and transfer over a shared trans- 
mission channel present a challenge to the security of 
sensitive information. Internet and Intranet are two 
examples of such a shared information transmission chan- 
neling which many computers are connected with one 
another by local or wide area communication networks. It is 
therefore possible for any user or an intruder to intercept a 
package of sensitive data that is transmitted over the shared 
channel. In particular, the internet is a rapidly growing 
business forum and securing information transferred 
through its channels is becoming a major concern for 
transmitting proprietary information. Data encryption tech- 
niques can be used to increase the security in data exchange 
and transfer over a shared transmission channel. In its 
simplest form, data encryption uses a "key" based on a 
particular algorithm to change the sequence of a package of 
data that contains a piece of confidential information ("plain 
text") so that the data is enciphered or "scrambled" into an 
form that appears to have no correlation with the embedded 
confidential information ("cipher text"). An unauthorized 
user, who does not have the knowledge of either the encryp- 
tion method (e.g., the encryption algorithm) or the key 
formed based on the encryption method, cannot easily 
decode the information, An authorized user recovers the 
embedded information in the scrambled data by using a 
"key" that is constructed based on the encryption method. 
Therefore, even if the unauthorized user obtains the 
scrambled data, the knowledge of both of the encryption 
method and the particular key is needed to decrypt the 
confidential information embedded therein. 

One well-known encryption system is the Data Encryp- 
tion Standard (DES) adapted in 1977 by the National Bureau 
of Standards. This is a secret-key crypto system to exploit 
confusion and diffusion techniques, allowing acceptable 
security using key lengths as short as 64. The number of 
keys in crypto systems based on the DES can be as many as 
512 keys with the current computational power. However, 
increased key lengths "cost" significant delays in transmit- 
ting and receiving the encoded information. Two main kinds 
of crypto systems are a symmetrical system, i.e., the private 
key system, and an asymmetrical system, i.e., the public- 
private key system. The DES symmetric crypto systems 
typically encrypt 64 bit blocks of plain text using a key 
length of 56 bits. The fundamental building blocking DES 
(referred to as a round) is a single combination of a substi- 
tution followed by a permutation of the text, based on the 
key. 
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The plain text is encoded through 1 6 rounds of a function, 
which usually implement substitution, permutation, XOR 
and shift operations on subsets of the text and the key in such 
a way that every bit of the cipher text depends on every bit 
of the plain text and every bit of the key. This means that if 5 
a single bit of the cipher text is corrupted during 
transmission, the entire message may be lost. This is another 
weakness of DES-type block ciphers. In each round, a 
different subset of the elements from the key, Ki, are used to 
perform the encryption (hence Kl is applied during the first Q 
round, and Ki is applied during the ithround, etc.). An 
analogous algorithm is used to decrypt the cipher text, but 
the keys are now applied in reverse order, and the shift 
operations change from left to right. Given the complexity 
of the DES algorithm, the speed at which DES is encrypted 
is a function of the processor characteristics for both hard- 
ware and software implementations. For example, Digital 
Equipment Corporation makes a hardware DES chip which 
can encrypt and decrypt at a rate of lGBit/sec, or 15.6 
million DES blocks per second. Software implementations 
are slower; for example, an IBM 3090 mainframe can 
encrypt 32,000 DES blocks per second. 

Typical software implementation performances for micro- 
computers are listed in the Table 1 herein. TABLE 1 Encryp- 
tion Rates using some microprocessors Bus width DES 25 
Blocks Processor Speed (MHz) (bits) (per/sec) 8088 4.7 8 
37068000 7,6 16 90080286 6.0 16 1,10068020 16.0 32 
3,50068030 16.0 32 3,90080280 25.0 16 5,00068030 50.0 
32 9,60068040 25.0 32 16,00068040 40.0 32 23,20080486 
33.0 32 40,600. Another prior art cryptography system is the 30 
RSA Public Key Crypto system available from the RSA 
Data Security in California. RSA is an asymmetric crypto 
system in which two different keys are used: a public key to 
encrypt the plain text and a private key to decrypt the cipher 
text. The hardware implementations of RSA are usually 35 
about 1000 to 10,000 times slower than a hardware imple- 
mentation of DES. In software implementations, RSA is 
generally about 100 times slower than DES. These numbers 
will improve as technology advances, but the processing 
speed of RSA will be difficult to approach the speed of a 40 
symmetric crypto system. Consequently, RSA is generally 
not viewed as a replacement for DES or any other fast bulk 
encryption algorithm. Instead, RSA is often used for secure 
key exchange without prior exchange of secrets. Hence a 
long message is encrypted with DES. 45 

The message is sent with its DES key encrypted via RSA 
public key encryption. Many other prior- art encryption 
systems are variations of the DES-type encryption. 
Generally, it is suspected that given the advanced state of 
computational processors, DES may no longer be safe 50 
against a brute -force attack, so alternatives have actively 
been sought since the late 1980's. In response to this need, 
several alternatives have been developed and are thought to 
be competitive with DES in terms of the e level of security 
provided. Examples of these systems include the following 55 
encryption methods. 

(1) Triple DES, This is a variation of DES where the plain 
text is encrypted with the DES algorithm by three different 
keys in succession. This s is c commonly accepted to be 
equivalent to increasing the size of the DES key to 112 bits. <jo 
Triple encryption of the plain text is the current method of 
dealing with misgivings about DES's security, but this is 
clearly done at the expense of the throughput rate for 
encrypting and decrypting messages. 

(2) REDOC, a block algorithm which has a 20 byte 65 
(160-bit key) and that operates on an 80 bit block. All of the 
manipulations, (i.e. substitutions, permutations, and key 



XOR's) are performed on bytes, which makes it more 
efficient in software than DES whose initial and final per- 
mutations are difficult to efficiently implement in software. 
In addition, the 160 bit key usually makes this algorithm 
very secure. 

(3) Khufu is a recently proposed 64 bit block cipher, 
which calls for a 512-bit key, and leaves the number of 
rounds open (either 16, 24, or 32). Because of the large key, 
and the potentially expanded number of rounds, the security 
of this algorithm is expected to be very high. However, 
increasing the number of rounds has the disadvantage of 
slowing the rate at which data can be encrypted. 

(4) IDEA is a 64-bit block cipher that utilizes a 128 bit 
key. It usually utilizes three basic operations, XOR, addition 
modulo 2 sup 16, and multiplication modulo 2 sup 16. The 
algorithm typically operates on 16-bitsub-blocks, which 
makes it efficient, even on 16 bit processors. Its current 
software implementations are about as fast as DES. In view 
of the limitations and disadvantages of the various prior-art 
encryption systems, the inventors of the p resent invention 
developed a new crypto system based on optical phase 
modulation and a corresponding implementation interface 
between a user computer and the network. An embodiment 
in accordance with the present invention can exchange any 
of these methods for enciphering information embedded in 
a digital bit stream prior to digitization and transmission 
over a shared network such as the internet. 

A holographic de-scrambler can be used at the receiving 
end in accordance with a preferred embodiment by an 
authorized user to decipher the information. One of many 
advantages of the present invention is the potential to 
achieve high rate of encryption/decryption (e.g., larger than 
1 Gbit/s) as optical fiber networks of high data rates (e.g., 
larger than 2.4 Gbit/s) become more common. In one of 
several preferred embodiments of the present invention, a 
package of digital data is first imprinted on a carrier light 
beam. This is done by using a two-dimensional spatial light 
modulator. The phase of the data-bearing optical waveform 
is subsequently distorted by a phase-scrambling medium. 
Next, the data-bearing optical waveform with distorted 
phase is used to form an optical hologram with a reference 
beam. The hologram is then converted into electronic signals 
which are sent to its destination in digital form over a shared 
transmission channel. At the destination where the 
scrambled data is received, the hologram is displayed in a 
spatial light modulator and a conjugate reconstruction 
thereof is performed to generate a conjugate of the data- 
bearing signal waveform with distorted phase. A holo- 
graphic medium having information indicative of the phase- 
scrambling medium is used to unscramble the phase and the 
embedded data is retrieved from the conjugate reconstruc- 
tion optical waveform by using a light detector array such as 
a CCD array. One aspect of the present invention is to 
achieve optical encryption keys up to and greater than 10 sup 
6 keys to enhance the security. 

This is a difficult implementation for many prior art 
systems. Such a large number of encryption keys is possible 
because of the unique optical analog technique in accor- 
dance with the present invention. It is another aspect of the 
present invention to insure fast enciphering and deciphering 
of a large encryption key that are rarely obtainable with the 
prior-art systems. The preferred embodiments implement 
this by using the high-speed optical reconstruction of a 
data-bearing hologram and the capability of parallel pro- 
cessing of optical data processing devices. It is yet another 
aspect of the present invention to increase the confidentiality 
of the encryption schemes by using unconventional analog- 
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based enciphering and deciphering of digital data. This 
aspect is particularly advantageous in view of the current 
lack of a theoretical foundation for decrypting analog-based 
encryption. A brute force attacked encryption based on 
algorithm techniques is nearly impossible for invading the 5 
cryptography systems in accordance with the present inven- 
tion. It is yet another aspect of the present invention to use 
optical phase information in a nonobvious way to encipher 
and decipher digital data. It is yet another aspect of the 
present invention that optical holographic techniques are 10 
used in both enciphering and deciphering processes to 
further enhance the confidentiality of the encryption systems 
in accordance with the present invention. It is yet another 
aspect of the present invention that the phase conjugate 
reconstruction of data-bearing holograms are implemented 15 
in preferred embodiments to ensure the high fidelity of the 
analog deciphering process. It is yet another aspect of the 
present invention to integrate optical processing technology, 
hardware encryption, opto-electronic interfacing, and high- 
fidelity and fast-speed digital signal transmission to form a 20 
highly secure, fast and versatile encryption system that 
works independent of the transmission media utilized. It is 
still another aspect of the present invention to complete the 
encryption or decryption process in a single step, instead of 
the 16 rounds of complex computations typically found in 25 
most symmetric encryption schemes. In the optical encryp- 
tion systems in accordance with the present invention, the 
encrypting speed is usually not limited by the size of the 
encryption key, but rather by the system speed in converting 
between the electro nic-to -optical and the optical-to- 30 
electronic information modes. 
Other Serialization 

In the past, merchants have unsuccessfully employed 
various methods in an attempt to track and identify their 
inventory. Engraving, stamping, painting, and marking are 35 
several methods that merchants have employed. Due to 
practical problems, those methods are not effectively appli- 
cable to the CD multimedia rental industry. 

As is known in the art and industry of compact disc 
multimedia, graphical information identifying the program 40 
title and author of a recording is ordinarily placed on the top 
surface of a CD. Digital data is stored on or just below that 
top surface. In particular, digital data is stored immediately 
below such graphical information between the top surface 
and the bottom surface of the CD. The bottom surface of the 45 
CD is comprised of a section of clear material through 
which, in accessing the data, a laser beam from a compact 
disc player radiates upward. 

The digital data is delicate and can easily be damaged 
during processes typically used to identify merchandise, 50 
which include engraving, stamping, or marking. As stated 
above, the digital data is closer to the top surface of the CD 
than it is to the bottom surface. Although the top surface of 
a CD usually contains graphical information applied by silk 
screening that partially protects the digital data from 55 
damage, the silk screened layer is thinner and more fragile 
than the bottom surface of a CD which comprises clear 
material. Thus, there is a greater need to protect the top 
surface of the CD and the digital data close to it from 
physical damage such as scratching. 60 

Engraving may be used to identify merchandise. Engrav- 
ing CDs with identification markings is problematic since 
engraving is often attempted on the top surface of the CD 
and such engraving could interfere with the digital data next 
to it. Moreover, even if engraving is attempted on the bottom 65 
surface of a CD where it is less likely that digital data will 
be damaged, the data may still be damaged during engraving 
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due to the pressure required to be placed on the top of the CD 
to hold it in place and the heat that may result from such 
engraving. In addition, engraving may be undesirable since 
it is a relatively labor intensive and costly process, especially 
in high volume situations. 

Thus, merchants have considered other less invasive 
methods of identification such as, for example, painting. 
Painting also fails to provide an effective means of identi- 
fication or security due to the labor required, the cost 
required, and the inherent unreliability of the process given 
the ease with which a person can duplicate such painting. 
Moreover, painting may pose other problems since harm to 
the digital data must be avoided. 

Still another option of identifying and securing inventory 
is the use of ordinary adhesive stickers. Such stickers do not 
provide an effective means of identification due to the ease 
with which such stickers can be removed and re affixed to 
similar looking items without a means of clearly indicating 
any tampering with the sticker. In addition, such stickers 
may be difficult to manually apply to CDs (since any sticker 
should be precisely centered on the CD) in the absence of an 
applicator workstation such as the one disclosed herein. In 
addition, such stickers may be easy to duplicate. 

Magnetic-type EAS systems are widely used to inhibit the 
theft of merchandise such as clothing, books, cassettes and 
compact disks. Electronic article surveillance (EAS) sys- 
tems are often used to prevent unauthorized removal of 
articles from a protected area, such as a library or retail store. 
An EAS system usually includes an interrogation zone or 
corridor located near the exit of the protected area and 
markers or tags attached to the articles to be protected. EAS 
systems have been based on magnetic, RF, microwave and 
magneto-restrictive technologies. Regardless of the particu- 
lar technology involved, the EAS systems are designed such 
that the tag will produce some characteristic response when 
exposed to an interrogating signal in the corridor. Detection 
of this characteristic response indicates the presence of a 
sensitized tag in the corridor. The EAS system then initiates 
some appropriate security action, such as sounding an 
audible alarm, locking an exit gate, etc. To allow authorized 
removal of articles from the protected area, tags that are 
either permanently or reversibly deactivatable (i.e., dual 
status tags) are often used. 

Although EAS markers have been in common use for the 
theft protection of optically recorded media such as compact 
disks and CD-ROM's, the markers have generally been 
adapted for attachment to the packages containing new 
compact disks and have been poorly suited for direct attach- 
ment to the compact disk itself for libraries and other 
institutions that repeatedly check compact disks in and out 
to accommodate the needs of customers and clients, effec- 
tive inventory control would prefer that EAS markers are 
attached to the compact disk. 

Some markers for direct attachment to compact disks 
have been developed. One, available as "DCD-1" from 
Minnesota Mining and Manufacturing Company, St. Paul, 
Minn., is a single marker strip and security overlay which 
are attached to a compact disk. However, this marker 
adversely effects the mechanical balance of the disk, which 
can adversely affect the operation of modern high rotation 
speed CD-ROM drives, CD players, and other optically 
recorded media playback equipment which require that the 
media be mechanically balanced for proper operation. 
Another product, "CD-Guard", available from Knogo North 
America, Inc., Hauppauge, Long Island, N.Y., suffers the 
same mechanical balance drawback. An optical information 
storage disk comprising an embedded, generally annular, 
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dual-status EAS marker is described in coassigned U.S. Pat. 
No. 5,347,508. 

Other Media 

It should be noted that the principles of the present 5 
invention may be applied to other types of media beyond the 
electronic storage medium discussed hereinabove. As a 
disk- like recording medium (referred to hereinafter as an 
optical disk) on and from which an information signal is 
recorded and reproduced by laser beam, there are now 10 
commercially available a so-called compact disc with audio 
data recorded therein, a CD-ROM in which computer data is 
recorded, a write once optical disk on which an information 
signal can be recorded once and a recordable optical disk in 
which an information signal can be reproduced, recorded 15 
and erased. 

The read-only optical disk such as a compact disc or 
CD-ROM has tracks on which irregular patterns, i.e., phase 
pits are concentrically or spirally formed on the basis of a 
recorded information signal formed on one surface thereof. 
Specifically, the read-only optical disk is composed of a disk 
base plate made of a transparent synthetic resin such as 
polycarbonate or PMMA (polymethyl methacrylate), a 
reflection film made of a metal such as Al or Au formed so 
as to cover phase pits formed on one surface of the disk base 
plate and a protection layer formed so as to cover the 
reflection film in order to protect the reflection film. 

When an information signal is reproduced from the read- 
only optical disk, laser beam from a laser light source is 30 
converged by an objective lens and irradiated on the read- 
only optical disk from the disk base plate side. Reflected 
light flux modulated by the phase pits on the optical disk is 
detected by a photodetector, for example, and converted into 
a detected signal having a signal level corresponding to an 35 
intensity of reflected light flux, thereby allowing a repro- 
duced signal of the information signal recorded on the 
read-only optical disk to be obtained. 

While the read-only optical disk can provide mass- 
produced products (optical disks) inexpensively on the 40 
market, it is not suitable for products of small demand. For 
this end, write once optical disks are prepared for optical 
disk products of small demand and a variety of data can be 
provided to the user easily. As write once optical disks, there 
are available a write once optical disk of recording system 45 
using physical chemical change of pigment, a write once 
optical disk of a single layer hole forming recording system, 
a write once optical disk of multi -layer hole forming record- 
ing system, a write once optical disk of phase -change 
recording system and a write once optical disk of bubble- 50 
foaming system. Upon reproduction, in a manner similar to 
the read-only optical disk, a laser beam (having a weak 
reproduction laser power) from a laser light source is 
irradiated on the disk from the disk base plate side under the 
condition that the laser beam is converged by an objective 55 
lens. Then, reflected light flux that is modulated by 
previously-recorded pits is detected by a photodetector and 
the detected signal is converted into a detected signal having 
a signal level corresponding to an intensity of a reflected 
light bundle, thereby obtaining a reproduced signal of an go 
information signal recorded on the write once optical disk. 

When an information signal is recorded on the above 
write once optical disk, a laser beam (having a strong 
recording laser power) from a laser light source is irradiated 
on the optical disk from the disk base plate side under the 65 
condition that the laser beam is converged by an objective 
lens. Then, the power of the laser beam is turned on and off 



by modulating the laser beam in response to an information 
signal and pits (pits substantially similar to those recorded 
on the read-only optical disk) corresponding to the infor- 
mation signal are formed along recording tracks of the 
optical disk. Specifically, in the case of the single layer hole 
forming recording system, a hole is formed on the recording 
track at an area irradiated with a strong laser beam and this 
hole is recorded as a pit. In the case of a multi-layer hole 
forming recording system, a hole is formed on the recording 
track at an area irradiated with a strong laser beam, e.g., the 
film of the first layer and the hole on the first layer are 
recorded as a pit. 

In the case of the phase change recording system, a 
portion of the recording track irradiated with a strong laser 
beam is changed from the amorphous state to the crystal 
state and the portion that was changed to the crystal state is 
recorded as a pit. In the case of the bubble foaming recording 
system, of the recording tracks, a recording layer of the 
portion irradiated with a strong laser beam is upheaved and 
the upheaved portion is recorded as a pit. 

In the write once optical disk, in particular, a guide groove 
is formed (pre-groove portion) to allow tracking control of 
laser beam. An end face opposing the pre-groove is formed 
as a sine wave shape (generally referred to as a wobble 
shape) having a predetermined amplitude and a predeter- 
mined period along the track. When this wobble shape is 
optically detected by laser beam, it is possible to obtain a 
wobble signal serving as absolute time information. The 
wobble signal is used to control the system of the recording 
and reproducing apparatus and, in particular, the timing 
information for recording pits on the optical disk. Further, 
the wobble signal is used to servo-control an optical disk 
rotating and driving means, e.g., a spindle motor. According 
to the servo control operation, the rotational speed of the 
spindle motor is controlled such that the period of the 
wobble signal becomes constant. 

The above write once optical disk is generally of a groove 
recording 10 system where pits are recorded on the pre- 
groove portion. When information data that is to be recorded 
on the write once optical disk is recorded, a target position 
is synchronously searched based on the period of the wobble 
signal obtained by optically detecting the wobble shape 
formed on the pre-groove portion. When the target position 
is detected, the above information data that is to be recorded 
on the write once optical disk is recorded on the target 
position according to a predetermined format. 

On the other hand, upon reproduction, a target position is 
searched as described above. When the target position is 
detected, based on a frame synchronizing signal inserted 
into the data to be recorded on the write once optical disk, 
2 kilobytes of data, for example, are sequentially read out, 
thereby reproducing recorded data. 

Since the read-only optical disk and the write once optical 
disk are the same in reproduction principle as described 
above, even when the write once optical disk is loaded onto 
a reproducing apparatus which reproduces an information 
signal from the read-only optical disk, data recorded on the 
write once optical disk can be reproduced without distinc- 
tion of the read-only optical disk. 

In addition, the write once optical disk has a feature that 
allows a number of optical disks to be easily produced by 
relatively simple equipment. For this reason, there is the risk 
that the write once optical disk will be illegally copied 
(illegal copy). Specifically, initially, there is a computer 
system wherein a reproducing apparatus for reproducing an 
information signal from a read-only optical disk is con- 
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nected to one external input and output terminal of a 
personal computer used by the end user. For example, and an 
external storage device for recording and reproducing an 
information signal on and from the write once optical disk 
is connected to another external input and output terminal. 5 
Then, recorded data that had been read out from the read- 
only optical disk by the reproducing apparatus are all written 
in the write once optical disk by the external storage device, 
thereby producing a pirate edition of the read-only optical 
disk. io 

In this case, if the read-only optical-disk is a CD-ROM 
where computer data (including computer program) are 
recorded, then a pirate edition of game software can be 
easily produced. If the read-only optical disk is a compact 
disc (CD) where music information are recorded, then it 15 
becomes possible to easily produce a pirate edition of the 
compact disc. Since computer programs are copyrighted 
material protected by copyright, copies — except those made 
by the regular user, i.e., registered users who accepted the 
software license agreement (software license agreement) — 20 
for backup or copies for the hard disk are illegal. 

Further, copy for thoroughly copying recorded data on the 
CD-ROM which is a copyright material to the write once 
optical disk for the purpose of action of concession in 
distribution is also illegal and such illegal action for obtain- 25 
ing unfair profit should be prevented. 

Furthermore, an act wherein a regular user makes a free 
distribution for those who are not regular users in an 
enterprise or CAI (Computer Assisted Instruction) is 
regarded as serious. 

At present, there are a variety of proposed methods for 
copy protection many of which have been reduced to 
practice. On the other hand, a software (program or the like) 
called "copy tool" used in removing copy protection is now 35 
commercially available. Short of the user's own conscience, 
there is currently no other way to prevent the illegal copying 
of recorded data. 

In view of the aforesaid, it is an object of the present 
invention to provide a data recording method wherein an 40 
illegal copy between disk-like recording mediums can be 
effectively protected even against a copy tool and in which 
copyrighted material (recorded data) recorded on the disk- 
like recording medium can be protected. 

Interactive productions allow a user of a computer system 45 
to interact with movies, video or other displayed images 
while the images are being updated at a rapid rate. The 
purpose of these productions is to present useful 
information, educate or entertain the user. The ultimate goal 
of interactive technology is to make the user feel as though 50 
they are interacting with images on the screen so that, for 
example, characters or objects in a drama react to the users 
actions. The user's actions can affect characters, objects or 
other images on the display screen and change the course of 
the storyline. 55 

One method for providing a high degree of interaction is 
to make the production completely computer generated. 
This means that the computer models a three dimensional 
world and calculates and displays the orientation of figures 
and objects on the screen. However, this approach is limited 60 
by today's technology because the computing power to fully 
calculate and render lifelike images, especially human 
figures, at resolutions approaching television quality in real 
time at video or film refresh rates is beyond the current 
technology for mass-marketed systems. 65 

A different approach is to prerecord video, film or com- 
puter generated image sequences and play the prerecorded 



images, or frames, back at high speed. This achieves the 
resolution of television, or better, and is sufEciendy lifelike 
to create a level of believability comparable to television. 
However, in this approach the user has a very limited 
amount of interactivity with the production since the user's 
ability to affect the story is limited to the small number of 
different "paths" of prerecorded image sequences that are 
branched to at predetermined decision points in the video or 
animation sequence. The use of any prerecorded sequences 
of images that are played back so as to achieve animation 
while allowing a user to interact with the images is referred 
to broadly here as "interactive video/' 

Interactive video productions typically use a compact disc 
read-only memory (CD-ROM) disc to store the images and 
a CD-ROM drive to retrieve images during playback. The 
CD-ROM disc stores information in a concentric spiral on 
optical media and is "read" or played back with a CD-ROM 
drive that uses a "read head" with a laser beam. The big 
problem with CD-ROM based interactive production is the 
break in continuity due to delays of about a half -second or 
more required to locate a desired branch path that is different 
from the current path that the drive's read head is tracking. 
Another problem is that CD-ROM based interactive video 
productions are severely limited in the number and types of 
ways that a user may interact with the video. 

The length of time to access a different video path 
("access time" or "seek time") depends upon the location of 
the different video path with respect to the current placement 
of the CD-ROM drive's read head. In order to access a given 
video sequence, a computer controller looks up the location 
of the sequence in an index and instructs the CD-ROM drive 
to access the new sequence by moving the read head to the 
beginning of the new sequence on the disc. Since the read 
head is moved by a mechanical mechanism it takes a 
comparatively long time to reposition the read head to a new 
point on the track to access the different video path. 

The prior art uses caches to try to improve the perfor- 
mance of accessing data in a CD-ROM. The cache can be in 
the CD-ROM drive, in an interface card between the pro- 
cessor and the drive, in the memory of the computer system 
controlled by software or even on a hard disk or other 
storage medium. However, these caches only provide mar- 
ginal improvement in access times where video is concerned 
because of the relatively small sizes of the caches compared 
to the data rate of the information coming off of the 
CD-ROM. Also, when a different path is branched to the 
information in the caches is usually useless since they don't 
contain the new data. The caches must be "purged" and 
loaded with new information. 

While current CD-ROM drives are not adequate to pro- 
vide sufficient interactivity in interactive video productions, 
they represent a huge installed base since hundreds of 
thousands have already been sold to consumers. Therefore, 
a system which eliminates the access time in CD-ROM 
based interactive videos without requiring modification of 
existing CD-ROM drives is desired. 

Conventionally, a so-called LD (Laser Disk) and a 
so-called CD (Compact Disk) are generalized as optical 
disks, on which information such as video information, 
audio information and the like is recorded. On the LD or the 
like, the video information and the audio information are 
recorded together with time information indicating a time at 
which each information is to be reproduced with respect to 
a reproduction start position, which each LD or the like has, 
as a standard position. Thus, other than a general normal 
reproduction to reproduce the recorded information in the 
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order of recording, various special reproductions are 2. The method for permitting selective access to data 

possible, such as a reproduction to extract and listen to an based on an identifier stored on an electronic storage 

only desirable music out of a plurality of recorded musics, medium as recited in claim 1 further comprising effecting a 

a reproduction to listen to the recorded musics in a random remote lmk betW een the device and the separate database to 

order and so on, in case of the CD, for example. s verify that a matching identifier already exists in the separate 

However, there is a problem that, according to the above , . , 

r database, 

mentioned LD or the like, a so-called interactive and var- _ „, A . , - . AA . , A . . , . 

, ... 3. The method for permitting selective access to data 

legated reproduction is not possible in which the audience , , .« 4 .~ , , . 4 

, , ri-i t r i based on an identifier stored on an electronic storage 

can have a plurality or selection branches as tor the video or j * i • 1 , . iU *• 

, , , , • m medium as recited in claim 1, wherein the verification 

audio information to be displayed or sound-outputted and in 30 . . , ... ., ^ . „ , . . , , 

, . . . „. , , , - includes combimng identifier information associated with 

the identifier and user information associated with the user 

and looking up both the identifier information and the user 

L . , , . , , J t information on the separate database, 

to be used tor a subtitle (caption) displayed on the picture _ A ^ 4 , , - . 4 . t , 4 

, , ^ , / . , . \ < . 15 4. The method for permittuig selective access to data 

plane (e.g., select one of the subtitle in Japanese and the , , • , .-^ . , i . 

, . , . . , , v , , . ■ , based on an identifier stored on an electronic storage 
subtitle in the original language) so as to display the subtitle 

in the selected language, or, in case of giving audience to a 

music recorded on the CD, it is not possible to select one of 



which the audience can select them to watch or listen to it. 
Namely, for example, in case of giving audience to a foreign 
movie on the LD, it is not possible to select one of Languages 



medium as recited in claim 1 further comprising storing for 

future reference a record of the steps of the method on the 

r . ■ r * n . ^ «. , separate database, 

sound voices of the music (e.g., select one of the English 20 r 

, . , , T , . v 5. The method for permitting selective access to data 

lyric and the Japanese lyric). * .-n * 1 1 ^ * , 

' r J ' based on an identifier stored on an electronic storage 

On the other hand, various proposals and developments medium ^ redted in daim x wherein ^ cma ^ Br ^ 

are being made as for the DVD, as an optical disk in which KmoUt[y ccmpled to tne separate daUbase yia a Qetwork 

the memory capacity is improved by about ten rimes without 2J „ The method for permitting Mfcctive access to data 

changing the size of the optical d 1S k itself as compared with based on aQ identifier stored on &Q electronic st 

the aforementioned conventional CD. With respect to this me&m ^ reci , ed ^ ^ 5> wnerein ^ QetwQrk ^ ^ 

DVD, if a plurality of subtitles in various languages or a internet 

plurality of voice sounds in various languages are recorded, ? ^ method for pemitting access to data 

the above mentioned interactive and variegated reproduction 30 ^ on aQ on ^ electronic storagc 

is possible as the audienc* selects one of them. medium M reci(ed m cIaim 5> wherein ^ daU fa embodied 

However, the information amount of the audio informa- on a we bsite 

lion or music information becomes enormous if the audio or 8 ^ m&thod for permitting selective access to data 

voice sounds in various languages or the music in various 35 based on an identifier stored on m electronic storage 

types are recorded on the above mentioned DVD. At this medium ^ redted in claim x wherein ±c clectronic storage 

time, if the information is not recorded m an appropriate me dium is an optical disc. 

recording form, the process for searching the audio infer- 9> ^ method for perm itting selective access to data 

mation etc. to be reproduced becomes complicated, and a based on aQ identiner stored on m electronic storage 

case where the audio sound or music sound etc. is inter- 40 medium as rec ited m daim 8, wherein the identifier is stored 

rupted in the middle of the reproduction due to the time on a burst cut area of the Qptical djsc 

required to search the audio information etc. may happen at 10 ^ method for permitting selective access to data 

the time of reproduction, which is a problem. based on an identifier stored on ^ electronic storage 

While various embodiments have been described above, 45 medium as recited in claim 1, wherein the data is stored in 

it should be understood that they have been presented by a remote database. 

way of example only, and not limitation. Thus, the breadth U. A computer readable medium embodying a computer 

and scope of a preferred embodiment should not be limited program for permitting selective access to data stored on a 

by any of the above^iescribed exemplary embodiments, but standalone electronic storage medium wherein the computer 

should be defined only in accordance with the following 50 p ro g ram comprises: 

claims and their equivalents. (a) a ^ segmenl for reading m identifier stored on the 

What is claimed is: electronic storage medium after inserting the electronic 

1. A method for permitting selective access to multimedia storage medium into the computer wherein the identi- 

data on a standalone electronic storage medium comprising ^ fier identifies a specific instance of the electronic stor- 

the steps of: age medium; 

(a) reading an identifier stored on the electronic storage (b) a code segment for transferring the identifier to a 
medium by software on a device after inserting the location of a separate database; 

electronic storage medium into the device wherein the (c) a code segment for verifying at the separate database 

identifier identifies a specific instance of the electronic 60 that a matching identifier already exists in the separate 

storage medium; database; and 

(b) transferring the identifier to a location of a separate (d) a code segment for precluding access to data in the 
database by software on the device; electronic storage medium upon unsuccessful verifica- 

(c) verifying at the separate database that a matching tion of the identifier 

identifier already exists in the separate database; and 65 12* T° e computer readable medium embodying a com- 

(d) precluding access to the data upon unsuccessful veri- puter program for permitting selective access to data based 
fication of the identifier. on an identifier stored on an electronic storage medium as 
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recited in claim 11 further comprising a code segment for 
effecting a remote link between the device and the separate 
database to verify that a matching identifier already exists in 
the separate database. 

13. The computer program for permitting selective access 5 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 11, wherein the verification 
includes combining identifier information associated with 
the identifier and user information associated with the user 10 
and looking up both the identifier information and the user 
information on the separate database. 

14. The computer readable medium embodying a com- 
puter program for permitting selective access to data based 
on an identifier stored on an electronic storage medium as 15 
recited in claim 11 further comprising a code segment for 
storing for future reference a record of the steps of the 
method on the separate database. 

15. The computer program for permitting selective access 2 q 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 11, wherein the computer is 
remotely coupled to the separate database via a network. 
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16. The computer program for permitting selective access 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 15, wherein the network utilizes 
an internet protocol. 

17. The computer program for permitting selective access 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 15, wherein the data is embodied 
on a website. 

18. The computer program for permitting selective access 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 11, wherein the electronic 
storage medium is an optical disc. 

19. The computer program for permitting selective access 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 18, wherein the identifier is 
stored on a burst cut area of the optical disc. 

20. The computer program for permitting selective access 
to data based on an identifier stored on an electronic storage 
medium as recited in claim 11, wherein the data is stored in 
a remote database. 

3}C 9^ ^ 9^ 
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